Intel bringt das Multicore-Problem in die Diskussion: In naher Zukunft soll es Prozessoren nicht nur mit 8 oder 16 Kernen geben, sondern mit Hunderten oder gar Tausenden. Die Software muss entsprechend angepasst werden, um diese Power zu nutzen.
Und das ist ziemlich komplex. Jedes Programm muss so entwickelt werden, dass es alle zur Verfügung stehenden Kerne nutzen kann. In einigen Fällen gibt es dafür bereits Lösungen: Raytracing soll zum Beispiel bestens skalieren und der nächste Knaller bei 3D-Spielen sein. Andere Algorithmen müssen erst noch entwickelt werden. Außerdem fehlt es noch an Tools, meistens werden nur Single Thread-Programme unterstützt.
In Zukunft reicht es also nicht mehr aus, einfach einen schnelleren Prozessor einzubauen, sondern die Software muss grundsätzlich anders entwickelt werden, um die Performance zu nutzen.
Müsste dafür nicht besser eine neue IDE entwickelt werden, die das für den Coder automatisch macht? Der einzelne Entwickler dürfte damit wohl überlastet sein, wenn er das selbst mit einplanen soll.?
Es wäre schön, wenn das so ginge, aber so lange ein Compiler nicht über die Intelligenz und die Krativität eines erfahrenen Programmierers verfügt wird daraus leider nichts.
Um das Ganze mal zu konkretisieren ein paar Beispiele:
Du hast als Aufgabe die Erstellung eines Filters für ein Foto. Der Filter soll das Foto in Schwarz-Weiß umwandeln. Das ist eine vorzügliche Aufgabe für Multiprocessing, denn es ist eine unabhängige Aufgabe... jedes Pixel wird anhand der RGB-Werte in entsprechende Grauwerte umgerechnet. Je nachdem wie viele physikalische (oder logische) Prozessoren das System hat teilst Du das Bild in Teilbilder auf. Sowas könnte auch ein Compiler noch erledigen.
Jetzt hast Du die Aufgabe einen Filter für ein Foto zu erstellen, der das Bild normalisiert, also den Unterschied zwischen dem hellsten Pixel und dem dunkelsten Pixel herausfindet und diese Differenz auf einen jeweiligen Höchst- und Niedrigstwert umrechnet. Jetzt wird es schon schwerer. Der erfahrene Programmierer erkennt, dass hier zwei getrennte Aufgaben vorliegen. Einmal die Analyse des Bildes zum Aufspüren der beiden Max-Werte und einmal die Aufgabe der Änderung der Einzelpixel.
Jeder Teil der Aufgabe ist parallellisierbar, jedoch nicht beide zusammen. Man kann mehrere Threads auf das Bild loslassen um die Max-Werte zu finden, man kann jedoch nicht die mehreren Threads drarauf loslassen es umzurechnen, so lange die Max-Werte gefunden sind. Hier wird es für einen Compiler schon schwieriger, da muss ihm der Programmierer schon helfen.
Jetzt hast Du die Aufgabe einen Filter zu erstellen, der ein Bild prüft, ob darin Text enthalten ist (OCR), der diesen Text auswertet, bestimmte Worte ersetzt und in eine neue Datei schreibt.
Der unerfahrene Programmierer würde sich jetzt denken, dass Teil 1 (erkennen von Text) nicht parallelisierbar ist, da es schwer wird für einen Trhead nur ein Viertel des Buchstaben "A" als solches zu erkenne, wenn er das Bild zerteilt. Der erfahrene Programmierer wird jedoch erkennen, dass ein Thread, der ein Bild nur nach Kontrasten scannt schneller ist, als einer, der in dem Bild nach Buchstaben sucht und ergo wird er einen Startthread programmieren, der mit geringen Kosten erst einmal schaut wo in dem Bild Text sein könnte. Auf diese Bereich schickt er dann die teuren OCR-Sanner in Form einzelner Threads los. Diese können dann parallel scannen und ersetzen. Bei dem letzten Teil, dem Schreiben in eine neue Datei, wird es dann wieder enger, dazu aber gleich mehr.
Was ich damit zeigen will ist, dass die Entscheidung ob etwas parallelisierbar ist oder nicht oftmals nicht-trivial ist. Ganz schwierig ist es im Bereich der Höheren Mathematik. Dort lassen sich Probleme erstmal nur dann parallel lösen, wenn man eine neue mathematische Herangehensweise entwickelt hat. Mit den normalen Modellen ist die Aufgabe streng linear. Wer jedoch imstande ist, dieses Problem zu lösen, der wird auch tunlichst dies entsprechend in Code umsetzen (und es auch können, oder wissen wer es kann). Die Entscheidung, ob etwas parallelisierbar ist kann also oft nur getroffen werden, wenn die Kenntnis über die Art der Aufgabe und deren Abhängigkeiten vorhanen ist... dies ist (derzeit) für Compiler definitiv eine zu anspruchsvolle Aufgabe, denn ein Compiler weiß nicht per sé, was eine Primzahl, was ein menschliches Auge auf einem Foto, oder was die Bedeutung des Wortes "Blödsinn" ist und wie diese mit Gott-und-der-Welt zusammen hängen. Dawird vielleicht in etwas fernerer Zukunft die KI so weit sein auch logische Zusammenhänge zu erfassen.
Aber mal zurück zum Artikel... die Programmierung der Software ist nur die halbe Wahrheit, denn die Zeiten in denen Software im Real-Mode lief sind lange vorbei. Heute hat das Betriebssystem und sein Sheduler die Oberhoheit über die Systemresourcen, wozu auch die CPU-Kerne gehören. Der Sheduler verteilt Prozesse und Threads, fragt deren Status ab und schickt sie nötigenfalls auf eine Extrarunde um den Platz, wenn sie so böse waren und die ganze Prozessorzeit für sich haben wollten und die anderen Schlange stehen mussten. Macht der Sheduler seine Aufgabe schlecht, dann kann der Programmierer sich bücken wie er will, schneller als der Sheduler es zulässt wird es nicht. Andererseits hat der Sheduler die nette Angewohnheit, dass er auch störrische Single-Threading-Anwendungen mit bestimmten Worten in ihre Schranken und auf einen freien Kern weisen kann. So kann sein ein schlauer Sheduler den Thread des Virenscanners auf CPU0, den Thread des Browsers (und von denen sind leider fast alle störrisch wenig muti-threading) auf CPU1, den Thread des Emailprogrammes auf CPU2 und was sich sonst noch tummelt auf CPU3 verweisen.
Nun kommen wir zum Kern der Sache... seit Microsoft nachdrücklich versuchte im Bereich des HPC (auf gut Deutsch: High Performance Computing) Fuß zu fassen wurde leider offensichtlich was vorher schon vermutet wurde: Der Windows-Kernel zählt nicht gerne, was bedingt, dass er sich mit vielen CPU-Kernen etwas schwer tut. Der Fachmann drückt das fogendermaßen aus: Er skaliert nicht gut. Vielleicht kennt der ein oder andere noch einen der Scherzkense, die sich in den frühen Jahren ein System mit 2 CPUs zulegten und darauf Windows 98 installierten... das war so effektiv wie die zweite CPU auf die Fensterbank zu legen, denn der Kernel von Windows 98 konnte nicht einmal bis zwei zählen, da hätte sich die Software und ihr Programmierer auf den Kopf stellen und mit den Zehen wackeln können. Will meinen, er hätte seine Aufgaben parallelisieren und in Threads zerlegen können bis zum umfallen... es wäre auf dem System einfach nicht gegangen (und es hat auch niemand versucht, eben weil es nicht ging).
Wenn man nun die bisherige Erfahrung heranzieht, dass sämtliche Microsoft-Kernel ab spätestens 8 logischen CPUs ein merkliches Problem mit den Fingern beim Abzählen bekommen, dann sollte man vielleicht erst einmal daran denken hier anzusetzen, bevor man die armen Anwenungsprogrammierer mit der Eselsmütze in der Ecke stehen lässt, denn es bringt nichts wenn sie ihre Probleme in 32 Threads packen die sich dann um 8 CPU-Kerne prügeln müssen. Da wäre es effektiver, wenn 4 Programmierer ihre Probleme in 8 Threads packen, die das schlae Betriebssystem auf 32 Kerne verteilt.
News: Multithreaded Software
xafford
The Wasp
