Paralleluniversum

Als Anwar Ghuloum 2002 zu Intel kam, war das Unternehmen die Nummer eins unter den Chipherstellern, vor allem weil es Prozessoren lieferte, die mit immer höheren Geschwindigkeiten liefen. Mit Pentium 4 waren wir bereits bei drei Gigahertz, und die Roadmap sah zukünftige Taktraten von 10 Gigahertz und mehr vor, erinnert sich Ghuloum, der bei Carnegie Mellon promoviert hat und heute einer der leitenden Ingenieure des Unternehmens ist. Im selben Jahr sagte Chief Technology Officer Pat Gelsinger auf der Intel-Entwicklerkonferenz: Wir sind bis 2010 auf dem richtigen Weg für 30-Gigahertz-Geräte, 10 Nanometer oder weniger, die eine Leistung von Tera-Anweisungen liefern. Das sind eine Billion Computeranweisungen pro Sekunde.





Aber Gelsinger lag falsch. Intel und seine Konkurrenten stellen immer noch Prozessoren her, die bei weniger als vier Gigahertz die Spitze erreichen, und etwas um fünf Gigahertz gilt, zumindest vorerst, als die maximal mögliche Geschwindigkeit für die Siliziumtechnologie.

Lebensader für erneuerbare Energien

Diese Geschichte war Teil unserer Januar-Ausgabe 2009

  • Siehe den Rest der Ausgabe
  • Abonnieren

Es ist nicht so, dass das Mooresche Gesetz – die Idee, dass sich die Anzahl der Transistoren auf einem Chip alle zwei Jahre verdoppelt – aufgehoben wurde. Vielmehr haben unerwartete Probleme mit der Wärmeerzeugung und dem Stromverbrauch die Taktraten der Prozessoren oder die Rate, mit der sie Befehle ausführen können, praktisch begrenzt. Neue Technologien wie die Spintronik (die die Spinrichtung eines einzelnen Elektrons verwendet, um Daten zu kodieren) und Quanten- (oder Tunnel-)Transistoren können Computer letztendlich um ein Vielfaches schneller als heute laufen lassen und dabei viel weniger Strom verbrauchen. Aber diese Technologien sind noch mindestens ein Jahrzehnt davon entfernt, den Markt zu erreichen, und sie würden den Ersatz von Halbleiterfertigungslinien erfordern, deren Bau viele Dutzend Milliarden Dollar gekostet hat.



Um das Beste aus den verfügbaren Technologien zu machen, gehen Chiphersteller also einen anderen Weg. Die vom Mooreschen Gesetz vorhergesagten zusätzlichen Transistoren werden nicht verwendet, um einzelne Prozessoren schneller zu machen, sondern um die Anzahl der Prozessoren innerhalb eines Chips zu erhöhen. Chips mit zwei Prozessoren – oder Kernen – sind heute der Desktop-Standard, und Vier-Kern-Chips werden immer häufiger. Langfristig sieht Intel Hunderte von Kernen pro Gerät vor.

Aber hier ist die Sache: Während sich das Hardwareproblem der überhitzten Chips gut für die Hardwarelösung des Multicore-Computing eignet, führt diese Lösung wiederum zu einem kniffligen Softwareproblem. Wie programmiert man für mehrere Prozessoren? Es ist die Aufgabe von Anwar Ghuloum, das herauszufinden, mit Hilfe von Programmiergruppen, die er in den USA und China leitet.

Mikroprozessor-Unternehmen gehen ein großes Risiko ein, wenn sie die Multicore-Strategie übernehmen. Wenn sie keine einfachen Wege finden, Software für die neuen Chips zu schreiben, könnten sie die Unterstützung der Softwareentwickler verlieren. Aus diesem Grund kam Sonys Multicore-Spielemaschine PlayStation 3 zu spät auf den Markt und hat immer noch weniger Spieletitel als seine Konkurrenten.



Das Problem mit Silizium
In den ersten 30 Jahren der Mikroprozessorentwicklung bestand der Weg zur Leistungssteigerung darin, Chips herzustellen, die immer kleinere Funktionen aufwiesen und mit immer höheren Taktraten liefen. Der ursprüngliche Apple II-Computer von 1977 verwendete einen 8-Bit-Prozessor, der mit einem Megahertz lief. Der PC-Standard ist heute ein 64-Bit-Chip mit 3,6 Gigahertz – effektiv 28.800-mal so schnell. Aber hier scheint dieser Weg zu enden. Bis etwa 2002 waren die kleinsten Strukturen, die mit Photolithographie auf einem Chip geätzt werden konnten, auf 90 Nanometer geschrumpft – eine Größenordnung, bei der unvorhergesehene Effekte dazu führten, dass ein Großteil der in jeden Chip gepumpten Elektrizität einfach entweicht und Wärme erzeugte, aber überhaupt keine Arbeit leistete . Inzwischen waren Transistoren so eng auf Chips gequetscht, dass die von ihnen erzeugte Wärme nicht absorbiert und abgeführt werden konnte. Als die Taktraten fünf Gigahertz erreichten, erkannten die Chiphersteller, würden Chips so heiß werden, dass ohne aufwändige Kühlsysteme das Silizium, aus dem sie hergestellt wurden, schmelzen würde. Die Branche brauchte einen anderen Weg, um die Leistung zu verbessern.

Aufgrund der komplexen Designs, die Hochgeschwindigkeits-Single-Core-Chips heute erfordern, können mehrere Kerne die gleiche Rechenleistung liefern und gleichzeitig weniger Strom verbrauchen. Weniger Strom erzeugt weniger Wärme. Darüber hinaus verteilt die Verwendung mehrerer Kerne die vorhandene Wärme.

Die meisten Computerprogramme wurden jedoch nicht mit Blick auf mehrere Kerne entwickelt. Ihre Anweisungen werden in einer linearen Reihenfolge ausgeführt, wobei nichts parallel passiert. Wenn Ihr Computer mehr als eine Aufgabe gleichzeitig zu erledigen scheint, liegt das daran, dass der Prozessor schneller zwischen Aktivitäten wechselt, als Sie es verstehen können. Der einfachste Weg, mehrere Kerne zu verwenden, war daher eine Arbeitsteilung – beispielsweise das Ausführen des Betriebssystems auf einem Kern und einer Anwendung auf einem anderen. Das erfordert kein ganz neues Programmiermodell und kann für die heutigen Chips mit zwei oder vier Kernen funktionieren. Aber was ist mit den von morgen, die 64 Kerne oder mehr haben können?



Wiedersehen alter Werke
Glücklicherweise, sagt Leslie Valiant, Professorin für Informatik und angewandte Mathematik an der Harvard University, seien die Grundlagen der Parallelität schon vor Jahrzehnten im Bereich des Hochleistungsrechnens – also mit Supercomputern – erarbeitet worden. Die Herausforderung, sagt Valiant, besteht jetzt darin, einen Weg zu finden, dieses alte Werk nutzbar zu machen.

Die Supercomputer, die Multicore-Computing inspirierten, waren Geräte der zweiten Generation der 1980er Jahre, die von Unternehmen wie Thinking Machines und Kendall Square Research hergestellt wurden. Diese Computer verwendeten zu Hunderten oder sogar Tausenden handelsübliche Prozessoren und liefen sie parallel. Einige wurden von der US-amerikanischen Defense Advanced Research Projects Agency als billigere Alternative zu Cray-Supercomputern in Auftrag gegeben. Die Erkenntnisse aus der Programmierung dieser Computer sind ein Leitfaden dafür, wie die Multicore-Programmierung heute funktioniert. Grand Theft Auto könnte also bald von der Softwareforschung profitieren, die vor zwei Jahrzehnten durchgeführt wurde, um das Design von Wasserstoffbomben zu unterstützen.

In den 1980er Jahren wurde klar, dass das Hauptproblem des Parallel Computing folgendes ist: Es ist schwer, Software zu zerlegen, damit sie von Hunderten von Prozessoren parallel verarbeitet werden kann, und sie dann in der richtigen Reihenfolge wieder zusammenzusetzen, ohne dass dies erlaubt wird beabsichtigtes Ergebnis beschädigt werden oder verloren gehen. Informatiker entdeckten, dass manche Probleme leicht parallelisiert werden können, andere jedoch nicht. Selbst wenn Probleme parallelisiert werden konnten, konnten die Ergebnisse dennoch ungeordnet zurückgegeben werden, was als Race Condition bezeichnet wurde. Stellen Sie sich zwei parallel laufende Operationen vor, von denen eine vor der anderen beendet werden muss, damit das Gesamtergebnis korrekt ist. Wie stellt man sicher, dass der Richtige das Rennen gewinnt? Stellen Sie sich nun zweitausend oder zwei Millionen solcher Prozesse vor.



Was wir aus dieser früheren Arbeit im Hochleistungsrechnen gelernt haben, ist, dass es Probleme gibt, die sich für Parallelität eignen, aber dass parallele Anwendungen nicht einfach zu schreiben sind, sagt Marc Snir, Co-Direktor des Universal Parallel Computing Research Center (UPCRC) an der Universität von Illinois in Urbana-Champaign. Normalerweise verwenden Programmierer spezialisierte Programmiersprachen und Werkzeuge, um Anweisungen für den Computer in Begriffen zu schreiben, die für den Menschen leichter verständlich sind als die Einsen und Nullen des Binärcodes. Aber diese Sprachen wurden entwickelt, um lineare Abfolgen von Operationen darzustellen; Es ist schwierig, Tausende von parallelen Prozessen durch eine lineare Reihe von Befehlen zu organisieren. Um von Grund auf parallele Programme zu erstellen, sind Sprachen erforderlich, die es Programmierern ermöglichen, Code zu schreiben, ohne darüber nachzudenken, wie er parallel gemacht werden kann – um wie gewohnt zu programmieren, während die Software herausfindet, wie die Anweisungen effektiv auf die Prozessoren verteilt werden. Es gibt noch keine guten Werkzeuge, um die Parallelität zu verbergen oder offensichtlich zu machen [wie man sie erreicht], sagt Snir.

Helle Lichter: 1987 veröffentlichte Thinking Machines seinen Supercomputer CM-2 (oben), in dem 64.000 Prozessoren parallel liefen. Das Unternehmen meldete 1994 Konkurs an, doch die Auswirkungen auf die Computer waren erheblich.

Um bei der Lösung solcher Probleme zu helfen, haben Unternehmen einige Graubärte des Supercomputings der 1980er Jahre zurückgerufen. David Kuck zum Beispiel ist ein emeritierter Professor an der University of Illinois, der als Entwickler von Tools für die parallele Programmierung bekannt ist. Jetzt arbeitet er an der Multicore-Programmierung für Intel. Ebenso ein ganzes Team, das von der ehemaligen Digital Equipment Corporation angeheuert wurde; in einem früheren Berufsleben entwickelte es Digitals Implementierung des Message Passing Interface (MPI), dem heute dominierenden Softwarestandard für Multimachine Supercomputing.

In gewisser Hinsicht haben es diese alten Spieler leichter als beim letzten Mal. Das liegt daran, dass sich viele der heutigen Multicore-Anwendungen stark von denen unterscheiden, die sich der legendäre Mainframe-Designer Gene Amdahl vorgestellt hat, der theoretisierte, dass der durch die Verwendung mehrerer Prozessoren erreichbare Geschwindigkeitsgewinn durch den Grad der Parallelisierung eines bestimmten Programms begrenzt war.

Computer verarbeiten größere Datenmengen als je zuvor, aber ihre Verarbeitungsaufgaben sind so ideal für die Parallelisierung geeignet, dass sich die Einschränkungen des 1967 beschriebenen Amdahl-Gesetzes wie keine Einschränkungen anfühlen. Das einfachste Beispiel für eine massiv parallele Aufgabe ist die Brute-Force-Ermittlung eines unbekannten Passworts durch Ausprobieren aller möglichen Zeichenkombinationen. Die Aufteilung der potenziellen Lösungen auf 1.000 Prozessoren kann nicht anders, als 1.000 Mal schneller zu sein. Dasselbe gilt für die heutigen prozessorintensiven Anwendungen zum Codieren von Video- und Audiodaten. Das parallele Komprimieren von Filmbildern ist fast perfekt effizient. Aber wenn Parallelverarbeitung für heute einfacher zu finden ist, ist es nicht unbedingt viel einfacher. Um es einfacher zu machen, bedarf es einer gemeinsamen Anstrengung von Chipherstellern, Softwareentwicklern und akademischen Informatikern. Tatsächlich wird UPCRC von Illinois von Microsoft und Intel finanziert – den beiden Unternehmen, die am meisten zu gewinnen haben, wenn Multicore-Computing erfolgreich ist, und am meisten zu verlieren, wenn es fehlschlägt.

Neue Werkzeuge erfinden
Wenn Software immer komplexer wird, liegt das nicht nur daran, dass ihr mehr Funktionen hinzugefügt werden; es liegt auch daran, dass der Code auf immer mehr Abstraktionsebenen aufgebaut ist, die die Komplexität dessen verbergen, was Programmierer wirklich tun. Dies ist nicht bloßes Aufblähen: Programmierer brauchen Abstraktionen, damit der grundlegende Binärcode die immer fortschrittlichere Arbeit verrichtet, die wir von ihm haben wollen. Wenn es um das Schreiben für Parallelprozessoren geht, verwenden Programmierer jedoch so rudimentäre Tools, dass James Larus, Direktor für Softwarearchitektur des Data Center Futures-Projekts bei Microsoft Research, sie mit der niedrigsten und schwierigsten Sprache vergleicht, die ein Programmierer verwenden kann .

Wir könnten uns nicht vorstellen, die heutige Software in Assembler zu schreiben, sagt er. Aber aus irgendeinem Grund glauben wir, dass wir parallele Software von gleicher Komplexität mit den neuen und kritischen Teilen schreiben können, die in einer parallelen Assemblersprache geschrieben sind. Wir können nicht.

Aus diesem Grund veröffentlicht Microsoft so schnell wie möglich Tools zur parallelen Programmierung. F# ist beispielsweise die parallele Version der universellen ML-Programmiersprache von Microsoft. Es parallelisiert nicht nur bestimmte Funktionen, sondern verhindert auch, dass sie unsachgemäß interagieren, sodass parallele Software einfacher zu schreiben ist.

Intel schickt Ghuloum unterdessen eine Woche im Monat ins Ausland, um mit Softwareentwicklern über Multicore-Architektur und Parallelprogrammierungsmodelle zu sprechen. Wir haben die Philosophie übernommen, dass das 'Problem' der Parallelprogrammierung in den nächsten ein oder zwei Jahren nicht gelöst sein wird und viele inkrementelle Verbesserungen – und eine kleine Anzahl von Sprüngen – bei bestehenden Sprachen erfordern, sagt Ghuloum. Ich neige auch dazu zu denken, dass wir dies nicht in einem Vakuum tun können; das heißt, ohne nennenswertes Feedback der Programmierer werden wir zweifellos in irgendeiner Weise am Falschen enden.

Sowohl auf dem kommerziellen als auch auf dem Open-Source-Markt nutzen andere neue Sprachen und Tools entweder die Leistungsfähigkeit der Multicore-Verarbeitung oder verschleiern ihre Komplexität. Dazu gehören das MapReduce-Framework von Google, das die Ausführung paralleler Berechnungen über Computercluster erleichtert, und Hadoop, eine Open-Source-Implementierung von MapReduce, die Anwendungen auf Tausende von Knoten verteilen kann. Neue Programmiersprachen wie Clojure und Erlang wurden von Grund auf für paralleles Rechnen entwickelt. Die beliebte Facebook-Chat-Anwendung wurde teilweise in Erlang geschrieben.

Inzwischen kann das MIT-Spinoff Cilk Arts Programme, die in der etablierten Sprache C++ geschrieben sind, in Threads aufteilen, die parallel auf mehreren Kernen ausgeführt werden können. Und Appistry mit Sitz in St. Louis behauptet, dass seine Enterprise Application Fabric Anwendungen für das .Net-Programmierframework von Microsoft automatisch auf Tausende von Servern verteilt, ohne dass Programmierer eine einzige Zeile ihres ursprünglichen Codes ändern müssen.

Die Grenzen von Multicore-Computing

So wie Intels Traum von 10- und 30-Gigahertz-Chips dem Streben nach Multicore-Computing gewichen ist, könnte Multicore selbst jedoch eher für Jahre als für Jahrzehnte existieren. Die Effizienz paralleler Systeme nimmt mit jedem hinzugefügten Prozessor ab, da die Kerne um die gleichen Daten wetteifern; Es wird einen Punkt geben, an dem das Hinzufügen eines zusätzlichen Kerns zu einem Chip ihn tatsächlich verlangsamt. Das könnte der Multicore-Strategie eine praktische Grenze setzen, lange bevor wir anfangen, Hundertkern-PCs zu kaufen.

Ist es trotzdem wichtig? Obwohl es Anwendungen geben kann, die die Leistung vieler Kerne erfordern, verwenden die meisten Benutzer diese Anwendungen nicht. Abgesehen von Hardcore-Gamern beschweren sich nur wenige Leute darüber, dass ihre PCs zu langsam sind. Tatsächlich hat Microsoft betont, dass Windows 7, der Nachfolger des angeschlagenen Windows Vista, weniger Rechenleistung und Speicher verbrauchen wird als Vista – ein Schritt, der aufgrund der Popularität von mobilen Computerplattformen mit geringerer Leistung und der erwarteten Migration von PC-Anwendungen auf Internetbasierte Server. Ein Zyniker könnte sagen, dass das Streben nach ständig steigender Rechenleistung rein kommerzieller Natur ist – dass Halbleiter- und Computerunternehmen, Softwarehersteller und Hersteller von Mobiltelefonen uns brauchen, um neue Geräte zu kaufen.

Was ist also der Nachteil, wenn Multicore-Computing fehlschlägt? Welche Auswirkungen hat es wahrscheinlich auf unsere Kultur, wenn wir einen technischen Zickzack nehmen, der eigentlich ein Zickzack hätte sein sollen und plötzlich nicht alle 64 Prozessorkerne in unseren zukünftigen Notebooks nutzen können?

Ich kann es kaum erwarten! sagt Steve Wozniak, der Erfinder des Apple II. Die Aufhebung des Mooreschen Gesetzes würde eine Renaissance der Softwareentwicklung auslösen, behauptet er. Nur dann werden wir endlich in der Lage sein, Software zu entwickeln, die auf einer stabilen und dauerhaften Plattform läuft.

In Schulen, sagt Woz, beträgt die Lebensdauer eines Schreibtisches 25 Jahre, eines Lehrbuchs 10 Jahre und eines Computers drei Jahre. Welches dieser Geräte kostet in Anschaffung und Betrieb am meisten? Natürlich der PC. Welches hat einen Restwert, wenn seine Nutzungsdauer abgelaufen ist? Nicht der PC – die Entsorgung kostet Geld. Zumindest Bücher können für Hitze verbrannt werden. Solange sich die Technologie nicht so verlangsamt, dass Computerplattformen lange genug halten, um wirtschaftlich rentabel zu sein, werden sie nicht wirklich ein wesentlicher Bestandteil der Bildung sein. Das Ende des Mooreschen Gesetzes mag also schlecht aussehen, wäre aber eigentlich sehr gut.

Robert X. Cringely schreibt seit 30 Jahren über Technologie. Er ist der Autor von Zufällige Imperien: Wie die Jungs aus dem Silicon Valley ihre Millionen verdienen, gegen ausländische Konkurrenz kämpfen und immer noch kein Date bekommen .

verbergen