-
Technisches Gebiet
-
Hierin beschriebene Ausführungsformen beziehen sich allgemein auf Prozessoren. Insbesondere beziehen sich die beschriebenen Ausführungsformen im Allgemeinen auf Prozessoren, die zum Optimieren von Befehlen zur Laufzeit konfiguriert sind.
-
Hintergrundinformation
-
Die parallele Verarbeitung ist im Allgemeinen schneller als die skalare Ausführung von jeweils einem Datenpunkt. SIMD (Single Instruction Multiple Data)-Computer mit einer Vielzahl von Verarbeitungselementen, welche die gleiche Operation an einer Vielzahl von Datenpunkten durchführen, erreichen Leistungsvorteile, weil sie die Parallelität und die gleichzeitige Verwendung einer Vielzahl paralleler Ausführungskerne vorteilhaft nutzen.
-
SIMD-Prozessoren können die Parallelität beim Durchführen von mathematischen Operationen und beim Bewegen von Daten vorteilhaft nutzen. SIMD-Prozessoren können eine Vielzahl von Datenelementen gleichzeitig laden oder speichern, was zu einer Leistungssteigerung gegenüber langsameren, skalaren Prozessoren führt, die jeweils nur ein Datum gleichzeitig laden oder speichern. Bei der Ausführung von Computerprogrammen auf einem Prozessor mit parallelen Ressourcen bietet die Verwendung von SIMD-Befehlen eine bessere Leistung als das Nutzen von skalaren Befehlen.
-
Die Programmierung unter Verwendung einer SIMD-Befehlssatzarchitektur (ISA) kann jedoch eine Herausforderung darstellen. Zum Beispiel sind SIMD-ISAs im Allgemeinen prozessorspezifisch. Programme, die SIMD-Befehle verwenden, müssen möglicherweise umgeschrieben und an eine neue Prozessorgeneration angepasst werden. Die Arbeit, die zum Anpassen von Skalarbefehlen an eine neue Befehlssatzarchitektur erforderlich ist, einschließlich Umschreiben des Codes, Dokumentieren des Codes; Ermöglichen der Emission des Codes von Kompilierern, Trainieren von Benutzern zur Verwendung des Codes und Debuggen und Sammeln von Spuren der Codeausführung müssen möglicherweise teilweise oder vollständig wiederholt werden, damit sie mit jeder neuen Generation von Befehlssatzarchitekturen wiederverwendet werden können (z. B. MMX, SSE, SSE2, SSE3, SSE4, AVX, AVX2, AVX 3.1 und AVX 3.2). Es wird daher ein Weg benötigt, um es Programmierern zu ermöglichen, die Vorteile von SIMD-Befehlssatzarchitekturen zu nutzen und gleichzeitig die mit herkömmlichen Lösungen einhergehenden Herausforderungen zu umgehen.
-
Des Weiteren sind herkömmliche Lösungen begrenzt, da sie den Code während der Ausführung vor der Zeit statisch und nicht dynamisch optimieren. Kompilierer versuchen, die Ausführung bestimmter Codesequenzen zu optimieren, aber sie arbeiten in einer statischen Umgebung, ohne den Maschinen- oder Registerzustand zu kennen. Sogar SIMD-Code, der gewöhnlich per Hand codiert wurde, kann den Code gemäß dem Laufzeit-Zustand der Maschine und der Register nicht optimieren. Es wird daher ein Weg benötigt, um Befehle zur Laufzeit zu optimieren und den Zustand der Register und ihrer Inhalte zu kennen.
-
Figurenliste
-
- 1 ist ein Blockflussdiagramm, das eine Prozedur für einen Prozessor zum kontextabhängigen Optimieren von Befehlen zur Laufzeit gemäß einer Ausführungsform veranschaulicht.
- 2 ist ein Blockdiagramm, das Verarbeitungskomponenten veranschaulicht, die von einem Prozessor verwendet werden, um Befehle zur Laufzeit gemäß einer Ausführungsform kontextabhängig zu optimieren.
- 3 veranschaulicht einen Befehl und seine verschiedenen Felder gemäß einer Ausführungsform.
- 4 veranschaulicht eine beispielhafte Registerzuteilung durch einen Prozessor, der den Vectorbeam-Code aus Tabelle 2 gemäß einer Ausführungsform optimiert.
- 5 veranschaulicht eine beispielhafte Zuteilung einer Vielzahl von Rechenressourcen, die zum parallelen Verarbeiten der zugewiesenen Register ausFig. 4 gemäß einer Ausführungsform verwendet werden.
- 6 veranschaulicht einen Teil einer Nachschlagetabelle, die Vektorbefehlsersetzungen für Skalarbefehle gemäß einer Ausführungsform auflistet.
- 7 veranschaulicht eine Vektorprozessor-Registerdatei gemäß einer Ausführungsform.
-
AUSFÜHRLICHE BESCHREIBUNG
-
In der folgenden Beschreibung sind zahlreiche spezielle Details dargelegt. Es versteht sich jedoch, dass Ausführungsformen der Offenbarung ohne diese spezifischen Details in die Praxis umgesetzt werden können. In anderen Fällen wurden hinlänglich bekannte Schaltungen, Strukturen und Techniken nicht im Detail gezeigt, um das Verständnis dieser Beschreibung nicht zu verschleiern.
-
Bezugnahmen in dieser Spezifikation auf „eine Ausführungsform“, „ein Ausführungsbeispiel“ usw. geben an, dass die beschriebene Ausführungsform ein bestimmtes Merkmal, eine bestimmte Struktur oder Eigenschaft aufweisen kann, jedoch nicht unbedingt jede Ausführungsform das bestimmte Merkmal, die bestimmte Struktur oder Eigenschaft aufweisen muss. Darüber hinaus beziehen sich solche Ausdrücke nicht unbedingt auf die gleiche Ausführungsform. Wenn ein bestimmtes Merkmal, eine bestimmte Struktur oder Eigenschaft in Verbindung mit einer Ausführungsform beschrieben wird, wird ferner geltend gemacht, dass es im Wissensbereich eines Fachmannes liegt, wie auf ein solches Merkmal, eine solche Struktur oder Eigenschaft in Verbindung mit anderen Ausführungsformen, seien sie explizit beschrieben oder nicht, Einfluss zu nehmen ist.
-
Ein (z. B. Hardware-)Prozessor oder ein Satz von Prozessoren führt Befehle aus einem Befehlssatz aus, z. B. der Befehlssatzarchitektur (ISA). Der Befehlssatz ist Teil der Rechnerarchitektur bezüglich der Programmierung und beinhaltet im Allgemeinen die nativen Datentypen, Befehle, Registerarchitektur, Adressiermodi, Speicherarchitektur, Interrupt- und Ausnahmehandhabung und externe Eingabe und Ausgabe (I/O) auf. Es sei anzumerken, dass sich der hierin verwendete Begriff „Befehl“ auf einen Makrobefehl beziehen kann, z. B. einen Befehl, der dem Prozessor zur Ausführung bereitgestellt wird. Ein Prozessor (z. B. mit einem oder mehreren Kernen zum Decodieren und/oder Ausführen von Befehlen) kann Daten bearbeiten, um z. B. Arithmetik, Logik, Datenbewegung oder andere Funktionen durchzuführen.
-
Kontextabhängige Optimierung zur Laufzeit
-
Gemäß der Offenbarung optimiert ein Prozessor die Befehle zur Laufzeit kontextabhängig. Insbesondere optimiert der Prozessor eine Sequenz aus suboptimalen Befehlen dynamisch zur Laufzeit. Suboptimale Befehle, wie hierin verwendet, beziehen sich auf Befehle, welche die verfügbaren Ressourcen eines Prozessors weniger als voll nutzen, oder die optimiert werden können, um die Befehlssatzarchitektur eines Prozessors vorteilhaft zu nutzen. In einer Ausführungsform werden Sequenzen aus suboptimalen Befehlen in dem Befehlsspeicher gespeichert und sind von Start- und Endabgrenzungsbefehlen umgeben. Im Allgemeinen wird zum Zweck der Offenbarung die Sequenz aus suboptimalem Code, der von Start-der-Sequenz- und Ende-der-Sequenz-Befehlen umgeben ist, hierin als Vectorbeam-Code bezeichnet. Die Ansprüche werden durch den Namen Vectorbeam nicht beschränkt. In alternativen Ausführungsformen kann der Code durch verschiedene Namen referenziert werden. Die Vectorbeam-Befehle sind nicht auf bestimmte Opcodes oder Tastenkürzel beschränkt.
-
Gemäß einer offenbarten Ausführungsform ist ein Prozessor konfiguriert, um eine Vectorbeam-Codefolge von suboptimalen Befehlen zu erkennen, die Sequenz zwischenzuspeichern und auf eine Nachschlagetabelle zuzugreifen, um eine oder mehrere Befehle zu identifizieren, um einen oder mehrere der suboptimalen Befehle der Vectorbeam-Codesequenz zu optimieren.
-
Trennzeichen: Start-der-Sequenz und Ende-der-Sequenz
-
In einer Ausführungsform können der Start-der-Sequenz-Befehl und der Ende-der-Sequenz-Befehl gewählt werden, um dem Prozessor einen Hinweis darauf zu geben, wie die Codesequenz optimiert werden kann. In einer Ausführungsform kann ein Prozessor vermuten, dass die Sequenz aus suboptimalen Befehlen eine iterative Schleife ist, da der Sequenz aus suboptimalen Befehlen ein Start-der-Sequenz-Abgrenzungsbefehl „foreach“ vorausgeht, dem ein Ende-der-Sequenz-Abgrenzungsbefehl, „next“, folgt. Ähnlich kann in alternativen Ausführungsformen der Start-der-Sequenz-Befehl darauf hinweisen, dass die Sequenz aus suboptimalen Befehlen iterativ ist, indem Abgrenzungsbefehle „foreach“ oder „do until“ oder „repeat until“ oder „do while“ verwendet werden. Der Ende-der-Sequenz-Befehl kann ähnlich benannt werden, um seine Funktion nahezulegen. (Z. B. „end“, „exit“, „stop“, „continue“, „return“). Der Start-der-Sequenz- und der Ende-der-Sequenz-Befehl können auch vorbestimmte Werte aufweisen, die nicht für Menschen lesbar oder numerisch sind oder automatisch oder zufällig ohne menschliche Beteiligung ausgewählt wurden.
-
Sequenz aus suboptimalen Befehlen
-
Eine Sequenz aus suboptimalen Befehlen, wie hierin verwendet, bezieht sich auf Computerbefehle, welche die parallelen Ressourcen, die in einem Prozessor verfügbar sind, auf dem diese Befehle ausgeführt werden sollen, weniger als voll nutzen.
-
Zum Beispiel kann die Sequenz aus suboptimalen Befehlen eine iterative skalare Schleife sein, die, wie geschrieben, weniger parallele Ressourcen verwendet, als im Prozessor verfügbar sind.
-
Als ein weiteres Beispiel kann die Sequenz aus suboptimalen Befehlen zum Verwenden von 64-Bit-Register geschrieben worden sein, aber der Prozessor, auf dem diese Befehle ausgeführt werden sollen, kann 128-Bit-Register zur Verfügung haben.
-
Als ein weiteres Beispiel bezieht sich die Sequenz aus suboptimalen Befehlen auf Multimedia-Operationen, wie z. B. das Dimmen der Helligkeit eines Pixelbildschirms. In einem solchen Beispiel können skalare mathematische Operationen durch breite Vektorbefehle ersetzt werden.
-
Metadaten
-
Gemäß der Offenbarung kann der Start-der-Sequenz-Befehl Operanden aufweisen, die Metadaten an einen Prozessor bereitstellen, der die Vectorbeam-Codesequenz implementieren wird. In einer Ausführungsform geben die Metadaten dem Prozessor einen Hinweis, wie der Code zu optimieren ist. In einer Ausführungsform geht der Sequenz aus suboptimalen Befehlen ein Start-der-Sequenz-Befehl „for each rax, 0, 64, 1“ voraus. Die Metadaten“ rax, 0, 64, and 1" stellen dem Prozessor einen Hinweis bereit, dass der suboptimale Code unter Verwendung des Registers rax als ein Schleifenindex zu loopen ist, indem rax 64 mal variiert wird, beginnend bei 0, mit einer Schrittweite von 1 für jede Iteration.
-
Beschreibung der veranschaulichenden Ausführungsformen
-
1 ist ein Blockflussdiagramm, das eine Prozedur für einen Prozessor zum kontextabhängigen Optimieren von Befehlen zur Laufzeit gemäß einer Ausführungsform veranschaulicht. Spezifisch ruft ein Prozessor, der zum Ausführen einer Prozedur zum kontextabhängigen Optimieren von Anweisungen zur Laufzeit gemäß dem Blockflussdiagramm 100 konfiguriert ist, bei 102 einen Befehl ab, decodiert den Befehl bei 104 und testet bei 106, ob dieser im Optimierungsmodus ist. In einer Ausführungsform wird der abzurufende Befehl in einem Befehlspuffer gespeichert. In alternativen Ausführungsformen kann der Befehl in einem Befehlsregister, einem allgemeinen Register, einem Programmstapel oder einem Speicher, einschließlich eines statischen und dynamischen Direktzugriffsspeichers, gespeichert sein. Ein Prozessor, der die Prozedur von Ablaufdiagramm 100 durchführt, decodiert den abgerufenen Befehl (z. B. Makrobefehl) bei 104, um als eine Ausgabe eine oder mehrere Mikrooperationen, Mikrocode-Eintrittspunkte, Mikrobefehle, andere Befehle oder andere Steuersignale zu generieren.
-
Gemäß der Offenbarung wird eine Vectorbeam-Codesequenz, die aus einer Sequenz aus suboptimalen Befehlen besteht, in dem Speicher gespeichert, der ein Start-der-Sequenz-Befehl vorausgeht und der ein Ende-der-Sequenz-Befehl folgt. In einer Ausführungsform kann der Start-der-Sequenz-Befehl in einem für Menschen lesbaren Assembliercode codiert sein und derart definierte Tastenkürzel aufweisen, die nahelegen, wie die suboptimalen Befehle optimiert werden sollten. Zum Beispiel kann der Start-der-Sequenz-Befehl „for each“, oder „do until“, oder „repeat until“, oder „do while“, lauten, um einige Beispiele zu nennen. Der Ende-der-Sequenz-Befehl kann ähnlich benannt werden, um seine Funktion nahezulegen. (Z. B. „end“, „exit“, „stop“, „continue“, „return“, „abort“, „undo“, oder „commit“). Der Start-der-Sequenz- und der Ende-der-Sequenz-Befehl können auch vorbestimmte Werte aufweisen, die nicht für Menschen lesbar oder numerisch sind oder automatisch oder zufällig ohne menschliche Beteiligung ausgewählt wurden.
-
Die suboptimalen Codesequenzen des Vectorbeam-Codes werden in einer Ausführungsform zum Nachahmen skalarer Tastenkürzel geschrieben und scheinen einen skalaren und/oder seriellen Ausführungsfluss aufzuweisen, wodurch sie leicht zu verstehen und zu debuggen sind. Das Abgrenzen der suboptimalen Codesequenzen mit leicht verständlichen Trennzeichen kann die Lesbarkeit des Codes verbessern und kann dem Prozessor auch nahelegen, wie der Code zur Laufzeit zu optimieren ist.
-
Wenn der Prozessor bei 106 bestimmt, dass er nicht im Optimierungsmodus läuft, löst er den bei 114 auszuführenden decodierten Befehl aus und schreibt ihn bei 116 fest oder zieht ihn zurück.
-
Das Eintreten in den Optimierungsmodus erfolgt in einer Ausführungsform während der Laufzeit, wenn der bei 104 decodierte Befehl ein Start-der-Sequenz-Befehl ist, wie oben beschrieben. In einer anderen Ausführungsform tritt der Prozessor beim Einschalten oder nach dem Zurücksetzen in den Optimierungsmodus ein. In einer anderen Ausführungsform tritt der Prozessor implizit in den Optimierungsmodus ein, nachdem er eine bestimmte Sequenz aus Befehlen bei 102 abgerufen hat, diese bei 104 decodiert und einen oder mehrere suboptimale Befehle wie skalare Befehle oder Befehle aus einer älteren Befehlssatzarchitektur erkannt hat. In einer alternativen Ausführungsform tritt der Prozessor implizit zur Laufzeit als Reaktion auf ein vordefiniertes Laufzeit-Ereignis in den Optimierungsmodus ein.
-
Das Austreten aus dem Optimierungsmodus erfolgt in einer Ausführungsform zur Laufzeit, wenn der bei 104 decodierte Befehl ein Ende-der-Sequenz-Befehl ist, wie oben beschrieben. In einer alternativen Ausführungsform tritt der Prozessor aus dem Optimierungsmodus implizit nach dem Auftreten einer Bedingung aus, wie zum Beispiel nach fehlgeschlagener Identifizierung eines Ersetzungsbefehls für eine Zeit. In einer alternativen Ausführungsform bleibt der Prozessor unbegrenzt im Optimierungsmodus.
-
Falls der Prozessor bei 106 bestimmt, dass er bereits im Optimierungsmodus ist, oder falls der Prozessor einen Start-der-Sequenz-Befehl erkennt, reiht er den decodierten Befehl bei 107 in einen Befehlspuffer ein. Der Befehlspuffer ist in einer Ausführungsform eine Reihe von Allzweckregistern. In anderen Ausführungsformen kann der Befehlspuffer Befehlsregister, Skalarregister, Schieberegister, einen Stapelspeicher, einen statischen oder dynamischen RAM-Speicher oder einen Cache-Speicher nutzen.
-
Im Betrieb und zur Laufzeit vergleicht der Prozessor die Befehle in dem Befehlspuffer bei 108 mit einer Nachschlagetabelle, um zu bestimmen, ob geeignete Ersetzungsbefehle verfügbar sind, einschließlich Ersetzungsbefehlen, die eine bessere Leistung erzielen würden. Bei der Auswertung bei 108, ob geeignete Ersetzungsbefehle verfügbar sind, wird der Prozessor in einer Ausführungsform durch die Metadaten geführt, die in dem Start-der-Sequenz-Abgrenzer enthalten sind. Bei der Auswertung bei 108, ob geeignete Ersetzungsbefehle verfügbar sind, wird der Prozessor in einer Ausführungsform durch den Zustand und die Inhalte der Registerdatei geleitet, wie weiter unten mit Bezug auf 7 beschrieben.
-
Beispiele des offenbarten Prozessors, der Vectorbeam-Code implementiert und durch Metadaten geführt wird, werden unten mit Bezugnahme auf Tabelle 1 und Tabelle 2 erläutert. In einer Ausführungsform umfassen die suboptimalen Befehle des Vectorbeam-Codes skalare Befehle und die Ersetzungsbefehle umfassen Vektorbefehle oder SIMD-Befehle. In einer Ausführungsform beinhalten die suboptimalen Befehle des Vectorbeam-Codes Befehle von einer Befehlssatzarchitektur der älteren Generation eines Prozessors, und die Ersetzungsbefehle werden aus dem Befehlssatz eines neueren Prozessors ausgewählt. In einer Ausführungsform besteht die Sequenz aus suboptimalen Befehlen des Vectorbeam-Codes aus einer iterativen Befehlsschleife, und die Ersetzungsbefehle schließen die Operation mit weniger Schleifen oder unter Verwendung von Vektorbefehlen ab. In einer anderen Ausführungsform besteht die Sequenz aus suboptimalen Befehlen in dem Befehlspuffer aus einer bedingten Schleife, und die Ersetzungsbefehle schließen die Operation mit weniger Schleifen oder unter Verwendung von Vektorbefehlen ab. Wenn der Prozessor bei 108 bestimmt, dass ein Ersetzungsbefehl verfügbar ist, der eine bessere Leistung erzielen würde, wählt er bei 110 einen oder mehrere Ersetzungsbefehle aus.
-
Bei 112 wählt der Prozessor den decodierten Befehl zur Ausführung aus, falls bei 108 keine Ersetzungsbefehle verfügbar waren, oder er wählt den einen oder die mehreren Ersetzungsbefehle aus, die bei 110 ausgewählt wurden. In einer Ausführungsform hält der Prozessor eine Sequenz aus Befehlen in dem Befehlspuffer und berücksichtigt eine Vielzahl von Befehlen, wenn er bei 108 mögliche Ersetzungen auswertet. In einer anderen Ausführungsform begrenzt der Prozessor die Anzahl der in dem Befehlspuffer gespeicherten Befehle, und, falls die Anzahl der Befehle diese Grenze überschreitet, entfernt der Prozessor einen oder mehrere Befehle aus dem Befehlspuffer und gibt sie aus, um bei 114 ausgeführt zu werden.
-
Bei 114 führt der Prozessor den decodierten Befehl oder den einen oder die mehreren Ersetzungsbefehle aus. Nach der Ausführung zieht der Prozessor den Befehl bei 116 zurück oder schreibt ihn fest, wobei sichergestellt wird, dass die Ausführungsergebnisse in ihre Ziele geschrieben werden oder dorthin geschrieben wurden, und Ressourcen für die spätere Verwendung werden befreit oder freigegeben.
-
2 ist ein Blockdiagramm, das Verarbeitungskomponenten veranschaulicht, die von einem Prozessor verwendet werden, um Vectorbeam-Codebefehle zur Laufzeit gemäß einer Ausführungsform kontextabhängig zu optimieren. Insbesondere beinhaltet das Blockdiagramm 200 den Befehlsspeicher 202, die Abrufschaltung 204, die Decodierschaltung 206, die Ausführungsschaltung 220 und die Rücksetz-/Festschreibungsschaltung 226. Die Decodierschaltung 206 weist eine Decodierlogik 208, einen Optimierungsmodusdetektor 210, einen Befehlspuffer 212, eine Nachschlagetabelle 214, eine Ersetzungs-Auswertelogik 216 und einen Befehlswähler 218 auf. Das Blockdiagramm 200 beinhaltet ferner eine Ausführungsschaltung 220, ein Register 222, einen Speicher 224 und eine Rücksetz-/Festschreibungsschaltung 226.
-
Im Betrieb nutzt der Prozessor die Abrufschaltung 204 zur Laufzeit, um einen Befehl aus dem Befehlsspeicher 202 abzurufen. In einer Ausführungsform ist der Befehlsspeicher 202 eine Registerdatei. In alternativen Ausführungsformen kann der Befehlsspeicher 202 ein Befehlspuffer, ein Befehlsregister, ein allgemeines Register, ein Programmstapel oder ein statischer und dynamischer Direktzugriffsspeicher sein.
-
Der Prozessor übergibt den abgerufenen Befehl an die Decodierschaltung 206, die den abgerufenen Befehl mit der Decodierlogik 208 decodiert. Der Befehl, einschließlich seines Opcodes und seiner optionalen Operanden, wird nachstehend unter Bezugnahme auf 3 beschrieben. Der Prozessor erkennt mit dem Optimierungsmodusdetektor 210, ob er sich im Optimierungsmodus befindet. Falls sich der Prozessor nicht im Optimierungsmodus befindet, sendet der Prozessor den decodierten Befehl an die Ausführungsschaltung 220.
-
Falls der Optimierungsmodusdetektor 210 jedoch erkennt, dass sich der Prozessor im Optimierungsmodus befindet oder den Prozessor in den Optimierungsmodus setzt, wird der decodierte Befehl in den Befehlspuffer 212 eingereiht. Wie gezeigt, hat der Befehlspuffer 212 vier Einträge, aber die Anzahl der Einträge ist variabel: sie könnte weniger als vier sein, sie könnte größer als vier sein, oder sie könnte dynamisch eingestellt werden, wie dem Fachmann verständlich ist. Zur Laufzeit verwendet der Prozessor die Ersetzungs-Auswertelogik 216, um die decodierten Befehle im Befehlspuffer 212 auszuwerten.
-
Insbesondere greift die Ersetzungs-Auswertelogik 216 zur Laufzeit auf die Nachschlagetabelle 214 zu, um zu bestimmen, ob irgendwelche Ersetzungsbefehle verfügbar sind. Die Nachschlagetabelle vergleicht in einer Ausführungsform die Tastenkürzel der suboptimalen Vectorbeam-Befehle in dem Befehlspuffer mit einer Auflistung von Ersetzungsbefehlen. In einer Ausführungsform sind die Ersetzungsbefehle Vektorbefehle. In einer anderen Ausführungsform sind die Ersetzungsbefehle SIMD-Befehle. In einer anderen Ausführungsform stammen die Ersetzungsbefehle von einer neueren Befehlssatzarchitektur als die suboptimalen Befehle. Bei der Auswertung von Ersetzungen wird die Ersetzungs-Auswertelogik 216 in einer Ausführungsform durch Metadaten geführt, die mit einem Start-der-Sequenz-Befehl bereitgestellt sind. Bei der Auswertung von Ersetzungen bewertet die Ersetzungs-Auswertelogik 216 in einer Ausführungsform den Laufzeit-Zustand der Prozessorregister. Falls zum Beispiel eine Vielzahl von Registern zum Bestimmen von Speicheradressen verwendet wird und falls diese Speicheradressen in dieselbe Cachezeile fallen, ersetzt die Ersetzungs-Auswertelogik 216 einen Vektorspeicherzugriff für Skalarspeicherzugriffe, die diesen Speicheradressen zugeordnet sind.
-
Falls in einer Ausführungsform die Ersetzungs-Auswertelogik 216 bestimmt, dass ein Ersetzungsbefehl verfügbar ist, wird der Ersetzungsbefehl an den Ausgabeselektor 218 weitergegeben, um zur Ausführung ausgegeben zu werden. In alternativen Ausführungsformen wird der Ersetzungsbefehl in den Befehlspuffer 212 geschrieben, um Befehle hinzuzufügen oder zu ersetzen. Wie gezeigt, verwendet die Decodierschaltung 206 den Ausgabeselektor 218, um Befehle auszuwählen, die entweder vom Befehlspuffer 212 oder von der Ersetzungs-Auswertelogik 216 ausgegeben werden.
-
Die Ausführungsschaltung 220 ist in einer Ausführungsform ein Vektorprozessor. In alternativen Ausführungsformen kann die Ausführungsschaltung 220 eine Vielzahl von Kernen und paralleler Hardware aufweisen. Die Ausführungsschaltung 220 benutzt in einer Ausführungsform die Register 222 und den Speicher 224, um Zwischenergebnisse zu speichern und anderenfalls die Ausführung zu unterstützen. Nach der Ausführung stellt die Rücksetz-/Festschreibeschaltung 226 sicher, dass die Ausführungsergebnisse in ihre Ziele geschrieben werden oder dorthin geschrieben wurden, und befreit oder gibt Ressourcen für die spätere Verwendung frei.
-
3 veranschaulicht einen Befehl und seine verschiedenen Felder gemäß einer Ausführungsform. Insbesondere beinhaltet der Befehl 300 einen Opcode 302 und optional erste, zweite und dritte Operandenidentifizierer 304, 306 bzw. 308. Der Opcode 302 identifiziert den Befehl und/oder die auszuführende Operation sowie den Typ von Operanden (z. B. „Start-der-Sequenz“ oder „Ende-der-Sequenz“). Die ersten, zweiten und dritten Operandenidentifizierer 304, 306 und 308 sind optional. In einer Ausführungsform ist der Opcode 302 ein „Start-der-Sequenz“-Befehl und der erste, der zweite und der dritte Operandenidentifizierer 304, 306 und 308 stehen für Metadaten, welche die folgenden suboptimalen Befehle beschreiben und dem Prozessor einen Hinweis geben oder nahelegen, wie die suboptimalen Befehle zu optimieren sind. In einer alternativen Ausführungsform ist der Opcode 302 ein „Start-der-Sequenz“ -Befehl, der eine iterative Sequenz aus folgenden suboptimalen Befehlen identifiziert, und der erste, der zweite und der dritte Operandenidentifizierer 304, 306 und 308 legen eine Anzahl von Schleifeniterationen, ein Register, das bei jeder Iteration variiert, und eine Schrittweite nahe, um welche die Variable bei jeder Iteration zu erhöhen ist. In einer alternativen Ausführungsform entspricht der Opcode 302 einem „Start-der-Sequenz“-Befehl, und einer oder mehrere der ersten, zweiten und dritten Operandenidentifizierer 304, 306 und 308 werden nicht verwendet. In einer alternativen Ausführungsform entspricht der Opcode 302 einem „Ende-der-Sequenz“-Befehl, und der erste, der zweite und der dritte Operandenidentifizierer 304, 306 und 308 werden nicht verwendet.
-
Tabelle 1 veranschaulicht eine beispielhafte Sequenz aus suboptimalen Befehlen, die gemäß einer Ausführungsform optimiert werden. Insbesondere zeigt der Seite-an-Seite-an-Seite-Code-Vergleich aus Tabelle 1 drei Versionen von Befehlen: Skalarcode, AVX-Code und Vectorbeam-Code, um die folgende Schleife zu implementieren, die als Code 1 bezeichnet wird:
Code 1. for (int i = 0; i < 64; i++) {outp[i] = inp1[i] + inp2[i];}
Tabelle 1.
Skalarcode |
..LOOP | Label-Schleife |
movss (%rsp,%rax,4), %xmm0 | 64 Bits von (Speicher) zu xmm0 bewegen |
movss 256(%rsp,%rax,4), %xmm1 | 64 Bits von (Speicher + 256) zu xmm1 bewegen |
addss %xmm1, %xmm0 | xmm0 + = xmm1 |
movss %xmm0, 512(%rsp,%rax,4) | 64 Bits von xmm0 zu (Speicher + 512) bewegen |
incq %rax | rax erhöhen |
cmpq $64, %rax | rax mit 64 vergleichen |
jl ..LOOP | 64 Mal loopen |
AVX-Code |
..LOOP | Label-Schleife |
vmovups (%rsp,%rax,4), %ymm0 | Vektor 256 Bits von (Speicher) zu ymm0 bewegen |
vmovups 256(%rsp,%rax,4), %ymm1 | Vektor 256 Bits von (Speicher + 256) zu ymm1 bewegen |
vaddps %ymm1, %ymm0 | Vektor ymm0 += ymm1 addieren |
vmovups %ymm0,512(%rsp,%rax,4) | Vektor 256 Bits von ymm0 zu (Speicher + 512) bewegen |
addq 8, %rax | 8 zu rax addieren |
cmpq $64, %rax | rax mit 64 vergleichen |
jl ..LOOP | 8 Mal loopen |
Vectorbeam-Code |
foreach rax, 0, 64, 1 | Start-der-Sequenz: auf rax von 0 bis 63 um 1 loopen |
movss (%rsp,%rax,4), %xmm0 | 64 Bits von (Speicher) zu xmm0 bewegen |
movss 256(%rsp,%rax,4), %xmm1 | 64 Bits von (Speicher + 512) zu xmm1 bewegen |
addss %xmm1, %xmm0 | xmm0 + = xmm1 |
movss %xmm0, 512(%rsp,%rax,4) | 64 Bits von xmm0 zu (Speicher + 512) bewegen |
next | |
-
Wie in Tabelle 1 gezeigt, weist der skalare Code eine Schleife auf, die 64 Mal auszuführen ist, wobei das rax-Register jedes Mal um eins erhöht wird. Der skalare Code ist suboptimal, da er möglicherweise nicht alle parallelen Ressourcen des Prozessors während seiner 64 Schleifeniterationen ausübt.
-
Der AVX-Code unterscheidet sich in mehrfacher Hinsicht vom Skalarcode. Die AVX-Register, ymm0 und ymm1 haben unterschiedliche Namen und unterschiedliche Größen. Die AVX-Opcodes haben unterschiedliche Namen. Die Iteration durch die Daten um 8 statt um 1 ist der Generierung von Prozessoren, die AVX zugeordnet sind, zueigen. Im Allgemeinen erfordert die Arbeit, die zum Erfinden von Skalarbefehlen, wie die Skalarbefehle aus Tabelle 1, zum Dokumentieren davon, zum Ermöglichen der Emission durch Kompilierer, zum Trainieren von Benutzern zur Verwendung davon und zum Debugging und Sammeln von Spuren ihrer Ausführung erfolgt, die teilweise oder vollständige Wiederholung zur Wiederverwendung mit jeder neuen Generation von Befehlssatzarchitektur (z. B. MMX, SSE, SSE2, SSE3 , SSE4, AVX, AVX2, AVX 3.1 und AVX 3.2).
-
Gemäß der Offenbarung werden jedoch im Vectorbeam-Code im Wesentlichen die gleichen Skalarbefehle mit im Wesentlichen dem gleichen Format verwendet. Spezifisch ist der Vectorbeam-Code-Körper von einem Start-der-Sequenz-Befehl, hier „foreach rax, 0, 64, 1“, und einem Ende-der-Sequenz-Befehl, hier „next“, umgeben. Wie codiert, gibt der „foreach“-Opcode in dem Start-der-Sequenz-Befehl einem Prozessor, der den Fluss 100 (1) implementiert, an, dass der zu befolgende suboptimale Code ein iterativer Code zu sein hat. Wie codiert, stellen die Operanden „rax“ „0“, „64“ und „1“ Metadaten bereit, die dem Prozessor nahelegen, den Fluss 100 (1) zu implementieren, um den suboptimalen Code unter Verwendung des Registers rax als einen Schleifenindex zu loopen, wobei rax von 0 bis 63 variiert, mit einer Schrittweite von 1 für jede Iteration. Mit anderen Worten legt der Start-der-Sequenz-Befehl dem Prozessor nahe, den Fluss 100 (1) zu implementieren, um den suboptimalen Code 64 Mal auszuführen, wobei rax jedes Mal um 1 variiert wird. Der Autor des ursprünglichen Skalarcodes kann die Vectorbeam-Codesequenz mit im Wesentlichen den gleichen Opcodes und im Wesentlichen den gleichen Formaten vorbereiten und es dem Prozessor überlassen, den Code zu optimieren. Der Prozessor wird den Vectorbeam-Code optimieren, um seine besonderen Hardwarefähigkeiten und seine Befehlssatzarchitektur vorteilhaft zu nutzen. Auf diese Weise kann die Codesequenz zum Implementieren von Code 1 zu neuen Generationen von Prozessoren und Befehlssatzarchitekturen ohne den Aufwand des Umschreibens, Neudokumentierens, Neuaktivierens, erneuten Testens, Umtrainierens, erneuten Debuggings und erneuten Veröffentlichens des Codes portiert werden. Entwickler können auch weniger Zeit damit verbringen, neue Opcodes und neue Registerdateien und andere Details zu lernen, die einer neuen Befehlssatzarchitektur zugeordnet sind, wenn ein neuer Prozessor verfügbar wird.
-
4 veranschaulicht eine beispielhafte Registerumbenennung durch einen Prozessor, der den Vectorbeam-Code aus Tabelle 1 gemäß einer Ausführungsform optimiert. Insbesondere muss der Vectorbeam-Code in dieser Ausführungsform von einem 128-Bit-Prozessor (z. B. SSE) ausgeführt werden, der eine Standardstrategie zum Erweitern von Vectorbeam-Kontexten um 4 aufweist. Daher muss das erste Mal durch den Prozessor Code für rax mit den Werten {0, 1, 2, 3} durchführen. Wenn der Prozessor den Vectorbeam-Befehl movss (%rsp,%rax,4),% xmm0 erreicht, muss er vier Ladevorgänge durchführen:
-
Wenngleich sich der Vectorbeam-Code aus Tabelle 1 auf die Architekturregister xmm0 und xmm1 bezieht, benennt der Prozessor, der den Vectorbeam-Code 400 aus 4 ausführt, die Architekturregister in physische Register um. (Wie dem Fachmann bekannt ist, kann der Prozessor, der den Code ausführt, eine große Anzahl von physischen Registern aufweisen, die als Architekturregister dienen, die in verschiedenen Programmthreads referenziert werden, wobei die Threads gleichzeitig oder Außer-Reihenfolge ausgeführt werden können.) Wie gezeigt, greift der Prozessor auf die Logisch-zu-Physisch-Register-Tabelle 404 zu, um zu bestimmen, wie die Architekturregister in physischen Registern abgebildet werden. Gemäß Tabelle 404 weist der Prozessor xmm0 und xmm1 den physischen Registerdateispeicherplätzen 4-7 und 12-15 zu.
-
5 veranschaulicht eine beispielhafte Zuteilung einer Vielzahl von Rechenressourcen, die zum parallelen Verarbeiten der zugewiesenen Register aus 4 gemäß einer Ausführungsform verwendet werden. Der 128-Bit-SSE-Prozessor wendet hier seine Kenntnis über seine verfügbaren Hardware-Ressourcen an, um den Code und die Registerumbenennung zu optimieren. Wie gezeigt, benennt der Prozessor gemäß der Offenbarung die xmm-Architekturregister in die physische Registerdatei 502 um. Die ausgewählte Registerzuteilung in dieser Ausführungsform ermöglicht es vier ALUs gleichzeitig, die Addition parallel durchzuführen, wie durch 504, 506, 508 und 510 in 5 angegeben.
-
Tabelle 2 veranschaulicht eine beispielhafte Sequenz aus suboptimalen Vectorbeam-Befehlen, die gemäß einer Ausführungsform optimiert werden. Insbesondere zeigt der Seite-an-Seite-an-Seite-an-Seite-Code-Vergleich aus Tabelle 2 vier Versionen von Befehlen: Skalarcode, SSE- Code, AVX3-Code und Vectorbeam-Code, um die bedingte Schleife von Code 2 wie nachstehend zu implementieren:
Code 2. for (int i = 0; i < PTS; i++) {if (cond[i]) {outp[i] = inp1[i] + inp2[i];}}
Tabelle 2.
Skalarcode | SSE-Code |
..LOOP | ..LOOP |
cmpl $0, 768(%rsp,%rax,4) | movups (%rsp,%rax,4), %xmm3 |
je ..FALSE | movdqu 768(%rsp,%rax,4), %xmm0 |
movss (%rsp,%rax,4), %xmm0 | pcmpe4 %xmm1, %xmm0 |
addss 256(%rsp,%rax,4), %xmm0 | addps 256(%rsp,%rax,4), %xmm3 |
movss %xmm0, 512(%rsp,%rax,4) | movups 512(%rsp,%rax,4), %xmm4 |
..FALSE | pxor %xmm2, %xmm0 |
incq %rax | blendvps %xmm0, %xmm3, %xmm4 |
cmpq $64, %rax | movups %xmm4, 512(%rsp,%rax,4) |
jl ..LOOP | addq $4, %rax |
| cmpq $64, %rax |
| jb ..LOOP |
AVX3-Code | Vectorbeam-Code |
..LOOP | foreach rax, 0, 64, 1 |
vmovups (%rsp,%rax), %zmml | cmpl $0, 768(%rsp,%rax,4) |
addb $16, %dl | e ..FALSE |
vpcmpd $4, 512(%rsp,%rax), %zmm0, %k1 | movss (%rsp,%rax,4), %xmm0 |
vaddps 256(%rsp,%rax), %zmm1, %zmm2 | addss 256(%rsp,%rax,4), %xmm0 |
vmovups %zmm2, 1624(%rsp,%rax)(%k1) | movss %xmm0, 512(%rsp,%rax,4) |
addq $64, %rax | ..FALSE |
cmpb $64, %dl | next |
jb ..LOOP | |
-
Wie gezeigt, ist der Skalarcode, wie der in Tabelle 1 und Tabelle 2 gezeigte Skalarcode, suboptimal, da er 64 Schleifen erfordert. Wenn der Skalarcode auf einem modernen Vektorprozessor laufen würde, würde er weniger parallele Hardwareressourcen benötigen, als verfügbar sind.
-
Wie bei AVX-Code (Tabelle 1) müsste ein Programmierer, der Skalarcode in SSE-Code umwandelt, neue Opcodes, neue Registersätze lernen und der SSE-Code stellt keinen Sprungbypass bereit. Im Allgemeinen erfolgt die Arbeit zum Erfinden, Dokumentieren, Ermöglichen des Emittierens durch Kompilierer der Skalarbefehle, Trainieren von Benutzern zum Verwenden davon und Debugging und Sammeln von Traces für den Code, die teilweise oder vollständig mit jeder Generation der Befehlssatzarchitektur (z. B. MMX, SSE, SSE2, SSE3, SSE4, AVX, AVX2, AVX 3.1 und AVX 3.2) zu wiederholen sind.
-
Der SSE-Code weist außerdem einige Schwachstellen auf. Da der SSE-Code keinen Sprungbypass aufweist, führt er zum einen die Mathematik für alle Spuren unabhängig durch und verwendet dann einen BLEND-Befehl, um die unberührten nicht-bedingten Werte mit denen im bedingten Block zu vereinen. Die Leistung leidet (ein BLEND ist etwa 1,5 x langsamer als ein normaler Speicher) - es werden mehr Register benötigt (5 ggü. 2). Wie beim AVX-Code (Tabelle 1) erfordert die SSE-Codegenerierung einen komplexen Kompilierer.
-
AVX3-Code, wie AVX-Code (Tabelle 1) unterscheidet sich in mehrfacher Hinsicht vom Skalarcode. Die AVX3-Register ymm0...n haben unterschiedliche Namen und unterschiedliche Größen. Die AVX3-Opcodes haben unterschiedliche Namen. AVX3 verwendet ,k' Register, die als Ergebnis eines Vergleichs gesetzt und dann in Kombination mit Speichern/Laden verwendet werden. Wie SSE-Code hat AVX3-Code keine Verzweigung; der Prozessor führt alle Opcodes unter allen Bedingungen aus. Im Allgemeinen muss also die Arbeit, die zum Erfinden, Dokumentieren, Ermöglichen des Emittierens durch Kompilierer von Skalarbefehlen, Trainieren von Benutzern zum Verwenden davon und Debugging und Sammeln von Spuren für den Code erfolgt, möglicherweise teilweise oder vollständig mit jeder Generation der Befehlssatzarchitektur (z. B. MMX, SSE, SSE2, SSE3 , SSE4, AVX, AVX2, AVX 3.1 und AVX 3.2) wiederholt werden.
-
Gemäß der Offenbarung können jedoch im Vectorbeam-Code im Wesentlichen dieselben Skalarbefehle (Tabelle 1) mit im Wesentlichen demselben Format verwendet werden. Spezifisch startet der Vectorbeam-Code mit einem Start-der-Sequenz-Befehl, hier „foreach rax, 0, 64, 1“, und Ende-der-Sequenz-Befehl, hier „next“. Wie codiert, gibt der „foreach“-Opcode einem Prozessor, der den Fluss 100 (1) implementiert, an, dass der zu befolgende suboptimale Vectorbeam-Code ein iterativer Code ist. Wie codiert, stellen die Operanden „rax“ „0“, „64“ und „1“ Metadaten bereit, die dem Prozessor nahelegen, den Fluss 100 (1) zu implementieren, um den suboptimalen Vectorbeam-Code unter Verwendung des Registers rax als einen Schleifenindex zu loopen, wobei rax von 0 bis 63 variiert, mit einer Schrittweite von 1 für jede Iteration. Mit anderen Worten wird der Prozessor, der den Fluss 100 (1) implementiert, angewiesen, den suboptimalen Code 64 Mal auszuführen, wobei rax jedes Mal um 1 variiert. Auf diese Weise kann die Codesequenz zum Implementieren von Code 1 zu neuen Generationen von Befehlssatzarchitekturen ohne den Aufwand des Neuschreibens, Neutestens und Neuveröffentlichens des Codes portiert werden. Entwickler können auch weniger Zeit damit verbringen, neue Opcodes und neue Registerdateien und andere Details zu lernen, die mit einer neuen Befehlssatzarchitektur einhergehen.
-
Darüber hinaus kann gemäß der Offenbarung der CPU-Architekt, der Kenntnis über die speziellen Ressourcen, Fähigkeiten und die Befehlssatzarchitektur hat, die einer bestimmten CPU zugeordnet ist, wählen, wie die Funktionen, die in der Sequenz der suboptimalen Vectorbeam-Befehle beschrieben sind, zu implementieren sind. Darüber hinaus können der Opcode 302 (3) und die Metadaten 304, 306 und 308 (3) Hinweise an den Prozessor zum Auswählen bereitstellen, welche Befehle die Sequenz aus suboptimalen Vectorbeam-Befehlen ersetzen sollen. Zum Beispiel kann der Start-der-Sequenz-Befehl den Prozessor wissen lassen, dass eine Anzahl von Speicherladungen oder -speichern denselben Offset nutzen. Oder der Start-der-Sequenz-Befehl kann einen Hinweis liefern, dass eine Anzahl von Speicherladungen oder -speichern zu derselben Cache-Zeile gehören. Oder der Start-der-Sequenz-Befehl kann einen Hinweis liefern, dass eine Anzahl von mathematischen Operationen den gleichen Operanden verwendet, wie es in einer Multimedia- oder Grafikcodeprogrammroutine der Fall ist, die Pixel einheitlich einstellt, beispielsweise durch Erhöhen der Helligkeit.
-
6 veranschaulicht einen Teil einer Nachschlagetabelle, die Vektorbefehlsersetzungen für Skalarbefehle gemäß einer Ausführungsform auflistet. Speziell listet die Tabelle 600 Skalarbefehle und ihre entsprechenden Vektoräquivalente zum Ausführen mathematischer Operationen auf: Addition, Subtraktion, Multiplikation, Division, Quadratwurzel, Maximum, Minimum, Reziprok und Reziprok der Quadratwurzel. Mit Bezug auf die Seite-an-Seite-Tabelle 600 beinhaltet in einer Ausführungsform die Sequenz aus suboptimalen Vectorbeam-Befehlen, die in dem Befehlspuffer 212 (2) gespeichert sind, eine Skalaraddition, ADDSS, und die Ersetzungs-Auswertelogik 216 ( 2) ersetzt eine Vektoraddition, ADDPS, für einen oder mehrere der suboptimalen Vectorbeam-Befehle.
-
7 veranschaulicht eine Vektorprozessor-Registerdatei gemäß einer Ausführungsform. Insbesondere beinhaltet die Registerdatei 700 Vektorregister 702 und Allzweckregister 704. Wie gezeigt, beinhalten die Vektorregister 702 32 zmm-Register 706, jeweils 512 Bits breit, 16 ymm-Register 708, jeweils 256 Bits breit, und 16 xmm-Register 710, jeweils 128 Bits breit. Als Teil der Auswertung der Ersetzungen für suboptimale Vectorbeam-Befehle im Befehlspuffer 212 (2) weist die Ersetzungs-Auswertelogik 216 (2) in einer Ausführungsform die Ergebnisse der 8 32-Bit-Skalaroperationen einem 256-Bit-ymm-Register zu.
-
In einer alternativen Ausführungsform wird eine Vectorbeam-Sequenz aus suboptimalen Befehlen durch Befehle von einer neueren Befehlssatzarchitektur ersetzt. In einer Ausführungsform wird eine Sequenz aus suboptimalen SSE-Befehlen, die 128-Bit-XMM-Register 704 verwenden, durch eine Sequenz aus AVX-Laufbefehlen ersetzt, die 256-Bit-YMM-Register 706 verwenden, und erreichen eine bessere Leistung, ohne dass der suboptimale Code von seinem Autor umgeschrieben werden muss. In einer anderen Ausführungsform wird eine Sequenz aus suboptimalen AVX-Befehlen, die YMM-Register 706 benutzen, durch eine Sequenz aus AVX-512-Befehlen ersetzt, die ZMM-Register 708 verwenden und eine bessere Leistung erreicht, ohne dass der suboptimale Code von seinem Autor umgeschrieben werden muss.
-
In einer alternativen Ausführungsform könnte der Opcode 302 (3) die bestimmte Befehlssatzarchitektur identifizieren, die den suboptimalen Befehlen zugeordnet ist, die im Befehlspuffer 212 (2) gespeichert sind. Die Ersetzungs-Auswertelogik 216 (2) könnte dann optimale Befehle ersetzen, die der Befehlssatzarchitektur des Prozessors für die suboptimalen Befehle zugeordnet sind.
-
In einer Ausführungsform sind die suboptimalen Befehle und die Ersetzungsbefehle beides Vektorbefehle, aber die Ersetzungsbefehle stammen von einer neueren Generation und verwenden breitere Register.