MAJC – Wikipedia

MAJC (Microprocessor Architecture for Java Computing) war ein Multi-Core, Multithreaded, Very Long Instruction Word (VLIW)-Mikroprozessordesign von Sun Microsystems von Mitte bis Ende der 1990er Jahre. Ursprünglich UltraJava-Prozessor genannt, war der MAJC-Prozessor auf die Ausführung von Java-Programmen ausgerichtet, deren “spätes Kompilieren” es Sun ermöglichte, mehrere günstige Designentscheidungen zu treffen. Der Prozessor wurde in zwei kommerzielle Grafikkarten von Sun veröffentlicht. Die gewonnenen Erkenntnisse zu Multi-Threads auf einem Multi-Core-Prozessor bildeten die Grundlage für spätere OpenSPARC-Implementierungen wie den UltraSPARC T1.

Design-Elemente[edit]

Verschieben Sie die Befehlsplanung in den Compiler[edit]

Wie andere VLIW-Designs, insbesondere Intels IA-64 (Itanium), versuchte MAJC, die Leistung zu verbessern, indem mehrere teure Operationen aus dem Prozessor und in die entsprechenden Compiler verschoben wurden. Im Allgemeinen versuchen VLIW-Designs, die Anweisungsplaner, die oft einen relativ großen Teil des gesamten Transistorbudgets des Prozessors ausmacht. Wenn dieser Teil der CPU von der Software entfernt wird, können diese Transistoren für andere Zwecke verwendet werden, oft um zusätzliche Funktionseinheiten hinzuzufügen, um mehr Befehle auf einmal zu verarbeiten, oder um die Größe des Cache-Speichers zu erhöhen, um die Zeit für das Warten auf Daten zu reduzieren aus dem viel langsameren Hauptspeicher kommen. Obwohl MAJC diese allgemeinen Konzepte teilte, unterschied es sich in einigen spezifischen Details von anderen VLIW-Designs und Prozessoren im Allgemeinen.

Verallgemeinerte Funktionseinheiten[edit]

Die meisten Prozessoren enthalten eine Reihe von separaten “Unterprozessoren”, die als . bekannt sind Funktionseinheiten die darauf abgestimmt sind, mit einem bestimmten Datentyp zu arbeiten. Zum Beispiel hat eine moderne CPU typischerweise zwei oder drei Funktionseinheiten, die der Verarbeitung von ganzzahligen Daten und Logikbefehlen gewidmet sind, bekannt als ALUs, während andere Einheiten Gleitkommazahlen, die FPUs, oder Multimediadaten, SIMD, handhaben. MAJC verwendete stattdessen eine einzige Mehrzweck-Funktionseinheit, die jede Art von Daten verarbeiten konnte. Theoretisch bedeutete dieser Ansatz, dass die Verarbeitung eines Datentyps länger dauern würde, vielleicht viel länger, als die Verarbeitung derselben Daten in einer für diesen Datentyp bestimmten Einheit. Auf der anderen Seite bedeuteten diese Universaleinheiten aber auch, dass keine großen Teile der CPU ungenutzt blieben, weil das Programm zu diesem bestimmten Zeitpunkt zufällig viele (zum Beispiel) Gleitkommaberechnungen durchführte.

Befehlspakete variabler Länge[edit]

Ein weiterer Unterschied besteht darin, dass MAJC “Befehlspakete” mit variabler Länge zulässt, die unter VLIW eine Reihe von Befehlen enthalten, von denen der Compiler festgestellt hat, dass sie gleichzeitig ausgeführt werden können. Die meisten VLIW-Architekturen verwenden Pakete fester Länge, und wenn sie keinen auszuführenden Befehl finden, füllen sie ihn stattdessen mit a NOP, die einfach Platz wegnimmt. Obwohl Befehlspakete mit variabler Länge die CPU etwas komplexer machten, verringerten sie die Codegröße und damit die Anzahl der teuren Cache verfehlt durch Erhöhen der Codemenge im Cache zu einem beliebigen Zeitpunkt.

Vermeidung von Verriegelungen und Blockierungen[edit]

Der Hauptunterschied bestand darin, dass der Compiler beim MAJC-Design dies vermeiden musste verriegelt, pausiert die Ausführung, während die Ergebnisse einer Anweisung verarbeitet werden müssen, damit die nächste ausgeführt werden kann. Zum Beispiel, wenn der Prozessor die Anweisungen erhält C = A + B, E = C + D, dann kann die zweite Anweisung erst ausgeführt werden, nachdem die erste abgeschlossen ist. Die meisten Prozessoren enthalten Sperren im Design, um diese Art von verriegelten Befehlen zu blockieren und neu zu planen, sodass einige andere Befehle ausgeführt werden können, während der Wert von C berechnet wird. Diese Verriegelungen sind jedoch im Hinblick auf die Chip-Realität sehr teuer und repräsentieren den Großteil der Logik des Befehls-Schedulers.

Damit der Compiler diese Verriegelungen vermeiden kann, müsste er genau wissen, wie lange die Ausführung jeder dieser Anweisungen dauern würde. Wenn beispielsweise eine bestimmte Implementierung drei Zyklen benötigt, um eine Gleitkommamultiplikation abzuschließen, würden MAJC-Compiler versuchen, andere Befehle einzuplanen, die drei Zyklen benötigen, um abzuschließen und die derzeit nicht angehalten sind. Eine Änderung der tatsächlichen Implementierung könnte diese Verzögerung jedoch auf nur zwei Befehle reduzieren, und der Compiler müsste sich dieser Änderung bewusst sein.

Dies bedeutet, dass der Compiler nicht an MAJC als Ganzes gebunden war, sondern a besondere Umsetzung von MAJC, jede einzelne CPU basiert auf dem MAJC-Design. Dies wäre normalerweise ein ernstes logistisches Problem; Betrachten Sie beispielsweise die Anzahl der verschiedenen Variationen des Intel IA-32-Designs, jede würde ihren eigenen dedizierten Compiler benötigen und der Entwickler müsste für jede eine andere Binärdatei produzieren. Es ist jedoch genau dieses Konzept, das den Java-Markt antreibt – tatsächlich gibt es für jede ISA einen anderen Compiler, und dieser wird auf dem Computer des Clients installiert und nicht auf dem des Entwicklers. Der Entwickler liefert nur eine einzelne Bytecode-Version seines Programms aus, und der Computer des Benutzers kompiliert diese auf die zugrunde liegende Plattform.

In der Realität stellt sich die Planung von Anweisungen auf diese Weise als sehr schwieriges Problem heraus. In der Praxis treffen Prozessoren, die versuchen, dieses Scheduling zur Laufzeit durchzuführen, auf zahlreiche Ereignisse, wenn die benötigten Daten außerhalb des Caches liegen und es keine andere Anweisung im Programm gibt, die nicht ebenfalls von solchen Daten abhängt. In diesen Fällen kann der Prozessor für längere Zeit stehen bleiben und auf den Hauptspeicher warten. Der VLIW-Ansatz hilft in dieser Hinsicht nicht viel; Obwohl der Compiler möglicherweise mehr Zeit damit verbringen kann, nach auszuführenden Anweisungen zu suchen, bedeutet dies nicht, dass er tatsächlich eine finden kann.

MAJC hat versucht, dieses Problem durch die Möglichkeit zu lösen, Code von anderen Threads auszuführen, wenn der aktuelle Thread im Speicher blockiert ist. Das Wechseln von Threads ist normalerweise ein sehr teurer Prozess, der als Kontextwechsel bekannt ist, und bei einem normalen Prozessor würde der Wechsel alle Einsparungen zunichte machen und die Maschine im Allgemeinen verlangsamen. Auf MAJC könnte das System den Status für bis zu vier Threads gleichzeitig im Speicher halten, wodurch der Kontextwechsel auf wenige Anweisungen in der Länge reduziert wird. Diese Funktion ist seitdem auf anderen Prozessoren erschienen; Intel bezeichnet es als HyperThreading.

MAJC ging mit dieser Idee noch einen Schritt weiter und versuchte, Daten und Anweisungen, die für Threads benötigt werden, vorab abzurufen, während sie ins Stocken geraten sind. Die meisten Prozessoren enthalten eine ähnliche Funktionalität für Teile eines Befehlsstroms, die als spekulative Ausführung bekannt ist, wobei der Prozessor beide möglichen Ergebnisse einer Verzweigung ausführt, während er auf die Berechnung der Entscheidungsvariablen wartet. MAJC führte den Thread stattdessen weiter, als ob er nicht angehalten wäre, und nutzte diese Ausführung, um alle Daten oder Anweisungen zu finden und zu laden, die bald benötigt würden, wenn der Thread aufhörte, anzuhalten. Sun bezeichnete dies als Raum-Zeit-Computing (STC) und es handelt sich um ein spekulatives Multithreading-Design.

Bis zu diesem Zeitpunkt hatten Prozessoren versucht, Parallelität in einem einzigen Thread zu extrahieren, eine Technik, die in Bezug auf abnehmende Renditen an ihre Grenzen stößt. Es scheint, dass das MAJC-Design im Allgemeinen versucht hat, Blockierungen durch Laufen zu vermeiden über Threads (und Programme) im Gegensatz zur Suche nach Parallelität in einem einzelnen Thread. Es wird allgemein erwartet, dass VLIW in Bezug auf Blockierungen etwas schlechter ist, da es schwierig ist, das Laufzeitverhalten zur Kompilierzeit zu verstehen, was den MAJC-Ansatz zur Behandlung dieses Problems besonders interessant macht.

Implementierungen[edit]

Sun baute ein einziges Modell des MAJC, den Zweikerner MAJC 5200, das das Herz der Sun Workstation-Grafikkarten XVR-1000 und XVR-4000 war. Viele der Multicore- und Multithreading-Designideen, insbesondere in Bezug auf die Verwendung mehrerer Threads, um Verzögerungen beim Abwürgen zu reduzieren, fanden jedoch ihren Weg in die Sun SPARC-Prozessorlinie sowie in Designs anderer Unternehmen. Darüber hinaus scheint die MAJC-Idee, den Prozessor so zu gestalten, dass er im Gegensatz zu Anweisungen so viele Threads wie möglich ausführen kann, die Grundlage des späteren UltraSPARC T1 (Codename Niagara) Entwurf.

Siehe auch[edit]

Weiterlesen[edit]

Externe Links[edit]