-
QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
-
Diese Anmeldung nimmt die Priorität der US-Provisional-Patentanmeldung mit dem Aktenzeichen 61/556,782, welche am 7. November 2011 eingereicht wurde, sowie die Priorität der US-Patentanmeldung mit dem Aktenzeichen 13/669,401, welche am 5. November 2012 eingereicht wurde, in Anspruch. Jede dieser Anmeldungen wird hiermit durch Bezugnahme hierin aufgenommen,
-
HINTERGRUND DER ERFINDUNG
-
Gebiet der Erfindung
-
Die vorliegende Erfindung bezieht sich im Allgemeinen auf Compiler für Parallelverarbeitungseinheiten (PPUs) und spezifischer auf eine Technik für live Analyse-basierte Rematerialisation (engl. „live analysis-based rematerialization”) zur Reduktion von Registerdruck (engl. „register pressure”) und zur Verbesserung von Parallelität.
-
Beschreibung des verwandten Standes der Technik
-
Graphikverarbeitungseinheiten (GPUs) sind mit der Zeit so entwickelt worden, dass sie zusätzlich zu graphikorientierten Operationen eine Vielzahl von Operationen unterstützen. Eine moderne GPU mag in der Tat dazu fähig sein, arbiträre Programmbefehle auszuführen. Eine solche GPU weist typischerweise einen Compiler auf, der Programmbefehle zur Ausführung auf einem oder mehreren Verarbeitungskernen kompiliert, die innerhalb der GPU enthalten sind. Jeder solche Kern mag einen oder mehrere verschiedenen Ausführungsthreads parallel zu anderen Verarbeitungskernen ausführen, die Ausführungsthreads ausführen.
-
Wenn ein Verarbeitungskern innerhalb der GPU eine Menge bzw. einen Satz von Programmbefehle ausführt, mag der Verarbeitungskern die Programmvariable, die mit diesen Befehlen assoziiert sind, in Registerspeicher speichern. Wenn der Registerspeicher von den Programmvariablen vollständig verbraucht ist, mögen zusätzliche Programmvariable in den Systemspeicher hinein „überlaufen” (engl. „spill”), wie es in der Technik bekannt ist. Ein Problem bei der konventionellen Vorgehensweise bzgl. „Überlaufens” ist, dass der Systemspeicher eine viel größere Latenz als der Registerspeicher hat. Folglich mag die Geschwindigkeit, mit der die Programmbefehle ausgeführt werden, dramatisch abfallen, nachdem ein „Überlauf”-Ereignis stattgefunden hat, da die Programmvariable aus dem Systemspeicher statt aus dem Registerspeicher abgerufen werden müssen. Ein zweites Problem ist, dass die Anzahl von Threads, die ein gegebener Verarbeitungskern innerhalb einer Verarbeitungseinheit simultan ausführen kann, von dem verfügbaren Registerspeicher abhängig ist. Das Auffüllen des Registerspeichers mit Programmvariablen mag folglich letztendlich dazu führen, dass die Anzahl von simultan ausführenden Threads reduziert wird, und demzufolge, dass der gesamte Verarbeitungsdurchsatz der GPU reduziert wird.
-
Folglich ist das, was auf dem technischen Gebiet benötigt wird, eine effizientere Technik zum Managen von Registerspeicher innerhalb einer GPU.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Eine Ausführungsform der vorliegenden Erfindung legt ein computerimplementiertes Verfahren zur Optimierung von Programmcode dar, der zur Ausführung auf einer Parallelverarbeitungseinheit (PPU) kompiliert werden kann, aufweisend ein Erzeugen eines Kontrollflussgraphen (engl. „control flow graph”) für den Programmcode, ein Identifizieren eines ersten Blocks in dem Kontrollflussgraphen, welcher Block im Vergleich mit anderen Blöcken in dem Kontrollflussgraphen die größte Anzahl von Live-in-Variablen aufweist, ein Auswählen einer ersten Teilmenge von Live-in-Variablen, die mit den ersten Block assoziiert sind, durch Ausführen einer Profitabilitätsanalyse (engl. „profitability analysis”) auf unterschiedlichen Teilmengen von Live-in-Variablen, die mit dem ersten Block assoziiert sind, und ein Optimieren des Programmcodes durch Rematerialisieren (engl. „rematerializing”) der ersten Teilmenge von Live-in-Variablen in einen zweiten Block in dem Kontrollflussgraphen, welcher zweite Block nachfolgend zu dem ersten Block in dem Kontrollflussgraphen ist, wobei der optimierte Programmcode auf der PPU ausgeführt werden soll.
-
Ein Vorteil der offenbarten Technik ist, dass das Rematerialisieren bestimmter Teilmengen von Live-in-Variablen den Registerdruck reduziert, wodurch die Wahrscheinlichkeit eines „Überlauf”-Ereignisses reduziert wird. Das Reduzieren des Registerdrucks erlaubt auch, dass eine größere Anzahl von Ausführungsthreads innerhalb einer PPU simultan ausgeführt wird, wodurch der gesamte Verarbeitungsdurchsatz der PPU erhöht wird.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
So dass die Art und Weise, in der die oben angeführten Merkmale der vorliegenden Erfindung im Detail verstanden werden kann, mag eine detailliertere Beschreibung der oben kurz zusammengefassten Erfindung durch Bezugnahme auf Ausführungsformen gehabt haben, von denen einige in der angehängten Zeichnungen dargestellt sind. Es muss aber bemerkt werden, dass die angehängten Zeichnungen nur typische Ausführungsformen der Erfindung illustrieren und somit nicht als den Umfang der Erfindung beschränkend angesehen werden dürfen, da die Erfindung andere gleich effektive Ausführungsformen zulassen mag.
-
1 ist ein Blockdiagramm, das ein Computersystem darstellt, das zum Implementieren eines oder mehrerer Aspekte der vorliegenden Erfindung konfiguriert ist;
-
2 ist ein Blockdiagramm von einem Parallelverarbeitungssubsystem für das Computersystem von 1, gemäß einer Ausführungsform der vorliegenden Erfindung;
-
3 zeigt einen Erstellungsprozess (engl. „build process”), der zum Kompilieren einer Coprozessor-geeigneten Anwendung (engl. „co-processor enabled application”) verwendet wird, gemäß einer Ausführungsform der vorliegenden Erfindung;
-
4 ist ein Flussdiagramm von Verfahrensschritten zur Ausführung von live Analyse-basierter Rematerialisation mit einer Menge von Live-in-Variablen, gemäß einer Ausführungsform der Erfindung;
-
5 ist ein Flussdiagramm von Verfahrensschritten zur Ausführung von einen Profitabilitätsanalyse auf einer Menge von Live-in-Variablen, gemäß einer Ausführungsform der Erfindung; und
-
6 legt einen beispielhaften Kontrollflussgraphen dar, um die Operation eines Geräte-Compiler-und-Linker (engl. „device compiler and linker”) zu illustrieren, gemäß einer Ausführungsform der vorliegenden Erfindung.
-
DETAILLIERTE BESCHREIBUNG
-
In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um ein eingehenderes Verständnis der vorliegenden Erfindung bereitzustellen. Es wird aber für einen Fachmann offenkundig sein, dass die vorliegende Erfindung auch ohne ein oder mehrere von diesen spezifischen Details ausgeübt werden kann.
-
Systemübersicht
-
1 ist ein Blockdiagramm, das ein Computersystem 100 zeigt, das zum Implementieren eines oder mehrerer Aspekte der vorliegenden Erfindung konfiguriert ist. Das Computersystem 100 weist eine zentrale Verarbeitungseinheit (engl. „central processing unit”) (CPU) 102 und einen Systemspeicher 104 auf, die über einen Verbindungspfad (engl. „interconnection path”), der eine Speicherbrücke 105 aufweisen mag, miteinander in Verbindung stehen bzw. kommunizieren. Der Systemspeicher 104 enthält ein Abbild eines Operativsystems 130, einen Treiber 103 und eine Coprozessor-geeignete Anwendung 134. Das Operativsystem 130 stellt detaillierte Befehle zum Managen und Koordinieren der Operation des Computersystems 100 bereit. Der Treiber 103 stellt detaillierte Befehle zum Managen und Koordinieren der Operation vom Parallelverarbeitungssubsystem 112 und einem oder mehreren darin residierenden Parallelverarbeitungseinheiten (PPUs) bereit, wie es unten in Verbindung mit der 2 detaillierter beschrieben wird. Der Treiber 103 stellt auch Kompilierungsmittel zum Erzeugen von Maschinencode bereit, der für solche PPUs spezifisch optimiert ist, wie es unten in Verbindung mit den 3–6 detaillierter beschrieben wird. Die Coprozessor-geeignete Anwendung 134 enthält Befehle, die auf der CPU 102 und den PPUs ausgeführt werden können, wobei diese Befehle in einem abstrakten Format implementiert sind, wie zum Beispiel virtuellem Assembler (engl. „virtual assembly”), und zu Maschinencode für die PPUs innerhalb des Verarbeitungssubsystem 112 mappt. Der Maschinencode für diese PPUs mag im Systemspeicher 104 oder in einem Speicher, der an die PPUs gekoppelt ist, gespeichert sein.
-
In einer Ausführungsform stellt die Coprozessor-geeignete Anwendung 134 CUDATM-Code dar, der Programmbefehle enthält, die für Ausführung auf dem Parallelverarbeitungssystem 112 bestimmt sind. Im Kontext der vorliegenden Beschreibung mag der Begriff „Anwendung” oder „Programm” auf jeglichen Computercode, jegliche Befehle und/oder jegliche Funktionen hinweisen, die unter Verwendung eines Prozessors ausgeführt werden können. In verschiedenen Ausführungsformen mag die Coprozessor-geeignete Anwendung 134 zum Beispiel C-Code, C++-Code usw. enthalten. In einer Ausführungsform mag die Coprozessor-geeignete Anwendung 134 eine Programmierspracheerweiterung von einer Computersprache enthalten (zum Beispiel C, C++ usw.).
-
Die Speicherbrücke 105, die zum Beispiel ein Northbridge-Chip sein mag, ist über einen Bus oder einen anderen Kommunikationspfad 106 (zum Beispiel einen HyperTransport-Link) mit einer Input/Output-(I/O)-Brücke 107 verbunden. Die I/O-Brücke 107, welche zum Beispiel ein Southbridge-Chip sein mag, erhält User-Input von einer oder mehreren User-Input-Vorrichtungen 108 (zum Beispiel Tastatur, Maus) und leitet den Input über den Kommunikationspfad 106 und die Speicherbrücke 105 an die CPU 102 weiter. Ein Parallelverarbeitungssubsystem 112 ist über einen Bus oder einen zweiten Kommunikationspfad 113 (zum Beispiel einen „Peripheral Component Interconnect Express” (PCIe), einen beschleunigten Grafikport (engl. „Accelerated Graphics Port”) (AGP), oder einen HyperTransport-Link) an die Speicherbrücke 105 gekoppelt; in einer Ausführungsform ist das Parallelverarbeitungssubsystem 112 ein Grafiksubsystem, das Pixel zu einer Displayvorrichtung 110 liefert, die jede konventionelle Kathodenstrahlröhre, Flüssigkristalldisplay, Lichtemittierende-Diode-Display oder ähnliches sein mag. Eine Systemdisk 114 ist auch mit der I/O-Brücke 107 verbunden und mag dazu konfiguriert sein, Inhalt und Anwendungen und Daten zu speichern, so dass diese von der CPU 102 und dem Parallelverarbeitungssubsystem 112 verwendet werden können. Die Systemdisk 114 stellt nicht flüchtigen Speicher für Anwendungen und Daten bereit und mag feste oder lösbare Festplattenlaufwerke, Flashspeichervorrichtungen und Compact-Disk-(CD)-Festspeicher (ROM), Digital-Video-Disk-(DVD)-ROM, Blu-Ray, High-Definition-(HD)-DVD oder andere magnetischen, optischen oder Festkörper-Speichervorrichtungen enthalten.
-
Ein Switch 116 stellt Verbindungen zwischen der I/O-Brücke 107 und anderen Bauteilen bereit, wie zum Beispiel einem Netzwerkadapter 118 und verschiedenen Erweiterungskarten (engl. „add-in cards”) 120 und 121. Andere (nicht explizit dargestellte) Bauteile, einschließlich Universal-Serial-Bus (USB) oder anderer Portanschlüsse (engl. „port connections”), CD-Laufwerke, DVD-Laufwerke, Filmaufzeichnungsvorrichtungen und ähnliches, mögen auch mit der I/O-Brücke 107 verbunden sein. Die verschiedenen Verbindungspfade, die in 1 gezeigt sind, einschließlich der spezifisch benannten Kommunikationspfade 106 und 113, mögen unter Verwendung von jeglichen geeigneten Protokollen, wie zum Beispiel PCIe, AGP, HyperTransport oder jedem anderen Bus oder Punkt-zu-Punkt-Kommunikationsprotokoll(en) (engl. „Point-to-Point Communication Protocol(s)”) implementiert sein, und Verbindungen zwischen verschiedenen Vorrichtungen mögen verschiedene Protokolle benutzen, wie es aus dem Stand der Technik bekannt ist.
-
Das Parallelverarbeitungssubsystem 112 weist in einer Ausführungsform Schaltkreise auf, die für Grafik- und Videoverarbeitung optimiert sind, einschließlich zum Beispiel Videoausgabeschaltkreise, und stellt eine Grafikverarbeitungseinheit (GPU) dar. In einer anderen Ausführungsform weist das Parallelverarbeitungssubsystem 112 Schaltkreise auf, die für Universalverarbeitung (engl. „general purpose processing”) optimiert sind, während die unterliegende rechnerische Architektur aufrechterhalten wird (wie es hierin detaillierter beschrieben wird). In noch einer anderen Ausführungsform mag das Parallelverarbeitungssubsystem 112 mit einem oder mehreren anderen Systemelementen in einem einzigen Subsystem integriert sein, wie zum Beispiel durch Zusammenführen der Speicherbrücke 105, der CPU 102 und der I/O-Brücke 107, um ein System-auf-Chip (engl. „system an chip”) (SoC) zu bilden.
-
Es wird verstanden werden, dass das hierin gezeigte System illustrativ ist und dass Variationen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung von Brücken, der Anzahl von CPUs 102 und der Anzahl von Parallelverarbeitungssubsystemen 112, mag wie gewünscht variiert werden. In einigen Ausführungsformen ist der Systemspeicher 104 zum Beispiel direkt mit der CPU 102 verbunden, statt durch eine Brücke, und andere Vorrichtungen kommunizieren über die Speicherbrücke 105 und die CPU 102 mit dem Systemspeicher 104. In anderen alternativen Topologien ist das Parallelverarbeitungssubsystem 112 mit der I/O-Brücke 107 oder direkt mit der CPU 102 verbunden, statt mit der Speicherbrücke 105. In noch anderen Ausführungsformen mögen die I/O-Brücke 107 und Speicherbrücke 105 in einem einzigen Chip integriert sein statt als eine oder mehrere diskrete Vorrichtungen zu existieren. Große Ausführungsformen mögen zwei oder mehr CPUs 102 und zwei oder mehr Parallelverarbeitungssubsysteme 112 aufweisen. Die jeweiligen hierin gezeigten Bauteile sind optional; zum Beispiel mag jede Anzahl von Erweiterungskarten oder Peripheriegeräten unterstützt werden. In einigen Ausführungsformen ist der Switch 116 entfernt und der Netzwerkadapter 118 und die Erweiterungskarten 120, 121 sind direkt mit der I/O-Brücke 107 verbunden.
-
2 zeigt ein Parallelverarbeitungssubsystem 112 gemäß einer Ausführungsform der vorliegenden Erfindung. Das Parallelverarbeitungssubsystem 112 weist, wie gezeigt, eine oder mehr Parallelverarbeitungseinheiten (engl. „Parallel Processing Units”) (PPUs) 202 auf, wobei jede von denen an einen lokalen Parallelverarbeitungs-(PP)-Speicher 204 gekoppelt ist. Im Allgemeinen weist ein Parallelverarbeitungssubsystem eine Anzahl U von PPUs auf, wobei U größer oder gleich 1 ist. (Hierin werden mehrere Instanzen ähnlicher Objekte mit Bezugszeichen, die das Objekt identifizieren, und Ziffern in Klammern, die, wenn nötig, die Instanz identifizieren, gekennzeichnet.) Die PPUs 202 und die Parallelverarbeitungsspeicher 204 mögen unter Verwendung einer oder mehrerer integrierten Schaltungsvorrichtungen implementiert werden, wie zum Beispiel programmierbare Prozessoren, anwendungsspezifische integrierte Schaltungen (engl. „Application Specific Integrated Circuits”) (ASICs) oder Speichervorrichtungen, oder in jeder anderen technisch realisierbaren Art und Weise.
-
In einigen Ausführungsformen sind, wieder mit Bezug auf sowie 1 als auch auf 2, einige oder alle der PPUs 202 in dem Parallelverarbeitungssubsystem 112 Grafikprozessoren mit Rendering-Pipelines, die dazu konfiguriert werden können, verschiedene Operationen in Bezug auf das Erzeugen von Pixeldaten aus Grafikdaten, die von der CPU 102 und/oder dem Systemspeicher 104 über die Speicherbrücke 105 und den zweiten Kommunikationspfad 113 bereitgestellt werden, auszuführen, mit lokalem Parallelverarbeitungsspeicher 204 (der als Grafikspeicher einschließlich, zum Beispiel, eines konventionellen Framepuffers benutzt werden kann) zu interagieren, um Pixeldaten zu speichern und zu aktualisieren, Pixeldaten an die Displayvorrichtung 110 zu übermitteln, und ähnliches. In einigen Ausführungsformen mag das Parallelverarbeitungssubsystem 112 eine oder mehrere PPUs 202 aufweisen, die als Grafikprozessoren arbeiten, und eine oder mehrere PPUs 202, die für Universalberechnungen (engl. „general-purpose computations”) benutzt werden. Die PPUs mögen identisch oder unterschiedlich sein, und jede PPU mag eine dedizierte(n) Parallelverarbeitungsspeichervorrichtung(en) oder keine dedizierte(n) Parallelverarbeitungsspeichervorrichtung(en) aufweisen. Eine oder mehrere PPUs 202 in dem Parallelverarbeitungssubsystem 112 mag bzw. mögen Daten an eine Displayvorrichtung 110 ausgeben oder jede PPU 202 in dem Parallelverarbeitungssubsystem 112 mag Daten an eine oder mehrere Displayvorrichtungen 110 ausgeben.
-
Im Betrieb ist die CPU 102 der Masterprozessor des Computersystems 100, welcher den Betrieb anderer Systembauteile steuert und koordiniert. Die CPU 102 erteilt insbesondere Befehle, die den Betrieb der PPUs 202 steuern. In einigen Ausführungsformen schreibt die CPU 102 einen Befehlsstrom für jede PPU 202 in eine (weder in 1 noch in 2 explizit gezeigte) Datenstruktur, die sich im Systemspeicher 104, Parallelverarbeitungsspeicher 204 oder in einer anderen Speicherstelle befinden mag, die für sowohl die CPU 102 als auch die PPU 202 zugreifbar ist. Ein Zeiger auf jede Datenstruktur wird in einen Stoßpuffer (engl. „push puffer”) geschrieben, um Verarbeitung des Befehlsstroms in der Datenstruktur zu initiieren. Die PPU 202 liest Befehlsströme aus einem oder mehreren Stoßpuffern aus und führt dann Befehle asynchron relativ zu dem Betrieb der CPU 102 aus. Ausführungsprioritäten mögen für jeden Stoßpuffer von einem Anwendungsprogramm über Gerätetreiber 103 festgelegt werden, um das Scheduling der verschiedenen Stoßpuffer zu steuern.
-
Jede PPU 202 weist eine I/O-(Input/Output)-Einheit 205 auf, die mit dem restlichen Computersystem 100 über Kommunikationspfad 113 kommuniziert, der mit der Speicherbrücke 105 (oder in einer alternativen Ausführungsform direkt mit der CPU 102) in Verbindung steht. Die Verbindung der PPU 202 an das restliche Computersystem 100 mag auch variiert werden. In einigen Ausführungsformen ist das Parallelverarbeitungssubsystem 112 als eine Erweiterungskarte implementiert, die in einen Erweiterungsslot (engl. „expansion slot”) des Computersystems 100 eingebracht werden kann. In anderen Ausführungsformen kann eine PPU 202 auf einem einzigen Chip mit einer Busbrücke, wie zum Beispiel Speicherbrücke 105 oder I/O-Brücke 107, integriert sein. In noch anderen Ausführungsformen mögen einige oder alle Elemente der PPU 202 auf einem einzigen Chip mit der CPU 102 integriert sein.
-
In einer Ausführungsform ist der Kommunikationspfad 113 ein PCIe-Anschluss (engl. „PCIe-link”), wie oben erwähnt, in welchem jeder PPU 202 dedizierte Spuren zugewiesen sind, wie es auf dem technischen Gebiet bekannt ist. Andere Kommunikationspfade mögen auch benutzt werden. Eine I/O-Einheit 205 erzeugt Pakete (oder andere Signale) für Transmission auf dem Kommunikationspfad 113 und empfängt auch alle ankommenden Pakete (oder anderen Signale) von dem Kommunikationspfad 113, wobei die ankommenden Pakete zu zweckmäßigen Bauteilen der PPU 202 geleitet werden. Befehle, die sich auf Bearbeitungstasks beziehen, mögen zum Beispiel zu einer Hostschnittstelle (engl. „host interface”) 206 geleitet werden, während Befehle, die sich auf Speichervorgänge (zum Beispiel Auslesen aus oder Schreiben auf den Parallelverarbeitungsspeicher 204) beziehen, zu einer Speicher-Kreuzschieneneinheit 210 geleitet werden mögen. Die Hostschnittstelle 206 liest jeden Stoßpuffer aus und gibt den Befehlsstrom, der in dem Stoßpuffer gespeichert ist, zu einem Frontend 212 aus.
-
Jede PPU 202 implementiert vorteilhafterweise eine in hohem Maße parallele Verarbeitungsarchitektur. Die PPU 202(0) weist, wie im Detail gezeigt, ein Verarbeitungscluster-Array (engl. „processing cluster array”) 230 auf, das eine Anzahl C von Allgemeinverarbeitungsclustern (engl. „general processing clusters”) (GPCs) 208 aufweist, wobei C ≥ 1. Jeder GPC 208 ist in der Lage, eine große Anzahl (zum Beispiel hunderte oder tausende) von Threads gleichzeitig auszuführen, wobei jeder Thread eine Instanz eines Programms ist. In verschiedenen Applikationen mögen unterschiedlichen GPCs 208 zur Verarbeitung unterschiedlicher Arten von Programmen oder zum Ausführen unterschiedlicher Arten von Berechnungen allokiert werden. Das Allokieren von GPCs 208 mag in Abhängigkeit von der Auslastung variieren, die für jede Art von Programm oder Berechnung entsteht.
-
Die GPCs 208 empfangen auszuführende Verarbeitungstasks von einer Arbeitsverteilungseinheit innerhalb einer Task/Arbeit-Einheit (engl. „task/work unit”) 207. Die Arbeitsverteilungseinheit empfängt Zeiger auf Verarbeitungstasks, die als Taskmetadaten (engl. „task metadata”) (TMD) kodiert und im Speicher gespeichert sind. Die Zeiger auf TMDs sind in den Befehlsstrom beinhaltet, der als ein Stoßpuffer gespeichert und mittels der Frontend-Einheit 212 von der Host-Schnittstelle 206 empfangen wird. Verarbeitungstasks, die als TMDs kodiert werden mögen, beinhalten Indices von zu verarbeitenden Daten sowie Zustandsparameter und Befehle, die definieren wie die Daten zu verarbeiten sind (zum Beispiel welches Programm auszuführen ist). Die Task/Arbeit-Einheit 207 empfängt Tasks von dem Frontend 212 und stellt sicher, dass die GPCs 208 zu einem gültigen Zustand konfiguriert sind, bevor die von jedem einzelnen der TMDs spezifizierte Verarbeitung eingeleitet wird. Eine Priorität mag für jede TMD, die zum Scheduling der Ausführung der Verarbeitungstasks benutzt wird, spezifiziert sein. Verarbeitungstasks können auch von dem Verarbeitungsclusterarray 230 erhalten werden. Die TMD können optional einen Parameter enthalten, der steuert, ob die TMD zu dem Kopf oder Ende von einer Liste von Verarbeitungstasks (oder Liste von Zeigern auf die Verarbeitungstasks) hinzugefügt wird, wodurch eine andere Stufe von der Steuerung der Priorität bereitgestellt wird.
-
Die Speicherschnittstelle 214 weist eine Anzahl D von Partitionseinheiten 215 auf, die jeweils direkt an einen Teil des Parallelverarbeitungsspeichers 204 gekoppelt sind, wobei D ≥ 1. Die Anzahl der Partitionseinheiten 215 ist, wie gezeigt, generell gleich der Anzahl von dynamischem RAM (DRAM) 220. In anderen Ausführungsformen mag die Anzahl der Partitionseinheiten 215 nicht gleich der Anzahl der Speichervorrichtungen sein. Durchschnittliche Fachleute werden verstehen, dass DRAM 220 durch andere geeignete Speichervorrichtungen ersetzt werden mag und von einer generell konventionellen Bauform sein kann. Eine detaillierte Beschreibung wird deswegen weggelassen. Render-Ziele, wie zum Beispiel Puffer- oder Strukturpläne, mögen quer über die DRAMs 220 gespeichert werden, was den Partitionseinheiten 215 ermöglicht, Teile von jedem Render-Ziel parallel zu schreiben, um die vorhandene Bandbreite des Parallelverarbeitungsspeichers 204 effizient zu nutzen.
-
Jeder der GPCs 208 mag Daten verarbeiten, die in irgendeinen der DRAMs 220 innerhalb des Parallelverarbeitungsspeichers 204 zu schreiben sind. Die Kreuzschieneneinheit 210 ist dazu konfiguriert, den Output jedes GPC 208 an den Input einer jeden Partitionseinheit 215 oder an einen anderen GPC 208 für weitere Verarbeitung zu leiten. Die GPCs 208 kommunizieren mit der Speicherschnittstelle 214 durch die Kreuzschieneneinheit 210, um aus bzw. in verschiedenen externen Speichervorrichtungen auszulesen bzw. zu schreiben. In einer Ausführungsform hat die Kreuzschieneneinheit 210 sowohl eine Verbindung zu der Speicherschnittstelle 214, um mit der I/O-Einheit 205 zu kommunizieren, als auch eine Verbindung zu dem lokalen Parallelverarbeitungsspeicher 204, wodurch es den Verarbeitungskernen innerhalb der verschiedenen GPCs 208 ermöglicht werden, mit dem Systemspeicher 104 oder einem anderen Speicher, der kein lokaler Teil der PPU 202 ist, zu kommunizieren. In der in 2 gezeigten Ausführungsform ist die Kreuzschieneneinheit 210 direkt mit der I/O-Einheit 205 verbunden. Die Kreuzschieneneinheit 210 mag virtuelle Kanäle benutzen, um Datenverkehrsströme zwischen den GPCs 208 und den Partitionseinheiten 215 zu separieren.
-
Wie erwähnt können die GPCs 208 zum Ausführen von Verarbeitungstasks, die sich auf eine umfangreiche Vielfalt von Applikationen beziehen, programmiert werden, einschließlich, aber nicht begrenzt auf, linearer und nicht-linearer Datentransformationen, Filtern von Video- und/oder Audiodaten, Modellierungsvorgänge (zum Beispiel der Anwendung von physikalischen Gesetzen zum Bestimmen von Position, Geschwindigkeit und anderen Eigenschaften von Objekten), Bild-Rendering-Vorgängen (zum Beispiel Mosaikshader-, Scheitelshader-, Geometrieshader- und/oder Pixel-Shaderprogramme (engl. „tesselation shader, vertex shader, geometry shader, and/or pixel shader programs”)), usw. Die PPUs 202 mögen Daten von dem Systemspeicher 104 und/oder den lokalen Parallelverarbeitungsspeichern 204 in einen internen (auf-dem-Chip) Speicher hinein übertragen, die Daten verarbeiten und die Ergebnisdaten zurück in den Systemspeicher 104 und/oder die lokalen Parallelverarbeitungsspeicher 204 schreiben, wo auf solche Daten von anderen Systembauteilen, einschließlich CPU 102 oder anderer Parallelverarbeitungssubsysteme 112, zugegriffen werden kann.
-
Eine PPU 202 mag mit jeder Menge lokaler Parallelverarbeitungsspeicher 204, einschließlich keiner lokalen Speicher, ausgestattet sein, und mag lokalen Speicher und Systemspeicher in jeder beliebigen Kombination benutzen. Eine PPU 202 kann zum Beispiel ein Grafikprozessor in einer Ausführungsform mit „unified memory architecture” (UMA) sein. In solchen Ausführungsformen würde wenig oder kein dedizierter Grafik-(Parallelverarbeitungs-)Speicher bereitgestellt werden, und die PPU 202 würde ausschließlich oder fast ausschließlich den Systemspeicher benutzen. In UMA-Ausführungsformen mag eine PPU 202 in einem Brückenchip oder Prozessorchip integriert sein oder als ein diskreter Chip mit einem Hochgeschwindigkeitsanschluss (beispielsweise PCI-Express), der die PPU 202 über einen Brückenchip oder ein anderes Kommunikationsmittel mit dem Systemspeicher verbindet, bereitgestellt werden. Alternativ mag jede PPU 202 mit einer nicht uniformen (engl. „non-uniform”) Speicherarchitektur implementiert werden und jede solche PPU 202 mag Zugriff auf mehrere verschiedenen Speicherräume haben, wie es von der Coprozessor-geeigneten Anwendung 134 angewiesen wird.
-
Wie oben erwähnt, kann eine beliebige Anzahl von PPUs 202 in einem Parallelverarbeitungssubsystem 112 enthalten sein. Mehrere PPUs 202 können zum Beispiel auf einer einzigen Erweiterungskarte bereitgestellt werden oder mehrere Erweiterungskarten können mit dem Kommunikationspfad 113 verbunden werden oder eine oder mehrere der PPUs 202 können in einem Brückenchip integriert werden. Die PPUs 202 in einem Mehrfach-PPU-System mögen gleich oder unterschiedlich voneinander sein. Unterschiedliche PPUs 202 mögen zum Beispiel eine jeweils unterschiedliche Anzahl von Prozessorkernen, unterschiedliche Mengen von lokalem Parallelverarbeitungsspeicher usw. aufweisen. Wenn mehrere PPUs 202 vorhanden sind, mögen diese PPUs parallel betrieben werden, um Daten mit einem größeren Durchsatz, als es mit einer einzigen PPU 202 möglich ist, zu verarbeiten. Systeme, die eine oder mehrere PPUs 202 aufweisen, mögen in einer Vielfalt von Konfigurationen und Formfaktoren implementiert werden, einschließlich Desktop-, Laptop- oder handgeführter Rechner, Server, Arbeitsstationen (engl. „workstations”), Spielkonsolen, eingebetteter Systeme und ähnliches.
-
Wie oben erwähnt, ist jede PPU 202 zum Ausführen der in 1 gezeigten Coprozessor-geeigneten Anwendung 134 konfiguriert. Die Coprozessor-geeignete Anwendung 134 wird von einer Geräte-Compiler-und-Linker-Anwendung kompiliert, die von dem Gerätetreiber 103 abgeleitet ist, wie es unten im Zusammenhagn mit 3 detaillierter beschrieben wird.
-
3 zeigt den Erstellungsprozess, der zum Kompilieren der Coprozessor-geeigneten Anwendung 134 von 1 verwendet wird, gemäß einer Ausführungsform der vorliegenden Erfindung. Der Programmcode 310 enthält Host-Quellcode 312 und Geräte-Quellcode 314. Der Host-Quellcode 312 enthält Programmbefehle, die dafür vorgesehen sind, auf einem Host, wie zum Beispiel einem ×86-basierten persönlichen Rechner (PC) oder Server, ausgeführt zu werden. Die Programmbefehle im Quellcode 312 mögen Aufrufe zu Funktionen enthalten, die in dem Geräte-Quellcode 314 definiert sind. Jeder technisch geeignete Mechanismus mag verwendet werden, um zu spezifizieren, welche Funktionen als Geräte-Quellcode 314 gekennzeichnet sind.
-
Der Host-Quellcode 312 wird vorverarbeitet, kompiliert und eingebunden (engl. „linked”) von einem Host-Compiler-und-Linker 322. Der Host-Compiler-und-Linker 322 erzeugt Hostmaschinencode 342, der innerhalb der Coprozessor-geeigneten Anwendung 134 gespeichert wird.
-
Der Geräte-Quellcode 314 wird vorverarbeitet, kompiliert und eingebunden von einem Geräte-Compiler-und-Linker 324. Diese Kompilierungsoperation bildet eine Kompilierung erster Stufe von dem Geräte-Quellcode 314. Der Geräte-Compiler-und-Linker 324 erzeugt virtuellen Geräte-Assembler 346, der innerhalb eines Geräte-Codespeichers 350 gespeichert wird, welcher sich bei oder innerhalb der Coprozessor-geeigneten Anwendung 134 befindet. Ein Übersetzer 334 virtueller Befehle mag Geräte-Maschinencode 324 aus dem virtuellen Geräte-Assembler 346 erzeugen. Diese Kompilierungsoperation bildet eine Kompilierung zweiter Stufe von dem Geräte-Quellcode 314. Der Übersetzer 334 virtueller Befehle mag mehr als eine Version von Geräte-Maschinencode 344 erzeugen, basierend auf der Verfügbarkeit von bekannten Architekturdefinitionen. Zum Beispiel mag der Übersetzer 334 virtueller Befehle eine erste Version vom Geräte-Maschinencode 344, die native 64-Bit arithmetische Befehle (die in der ersten Zielarchitektur zur Verfügung stehen) aufrufen, und eine zweite Version vom Geräte-Maschinencode 344 erzeugen, die 64-Bit arithmetische Befehle auf solchen Ziele emuliert, die keine native 64-Bit arithmetische Befehle enthalten.
-
Architekturinformation 348 kennzeichnet die tatsächliche Architekturversion, die zum Erzeugen des Geräte-Maschinencodes 344 verwendet wurde. Die tatsächliche Architekturversion definiert die Features, die in nativen Befehlen innerhalb eines tatsächlichen Ausführungsziels, wie zum Beispiel der PPU 202, implementiert sind. Die Architekturinformation 348 kennzeichnet auch die Version der virtuellen Architektur, die zum Erzeugen des virtuellen Geräte-Assemblers 346 verwendet wurde. Die virtuelle Architekturversion definiert die Features, die entweder als nativ oder leicht emulierbar zu sein angenommen werden, und die Features, die nicht zum Emulieren geeignet sind. Elementare (engl. „atomic”) Additionsoperationen sind zum Beispiel zum Emulieren auf der Befehlsebene nicht geeignet, obwohl sie auf der algorithmischen Ebene in bestimmten Fällen insgesamt vermieden werden mögen, und folglich beeinflussen mögen, welche Funktionen in der ersten Kompilierungsstufe kompiliert werden mögen.
-
Zusätzlich zu dem Geräte-Maschinencode 344 und virtuellen Geräte-Assembler 346 mag der Geräte-Codespeicher auch Architekturinformation 348 enthalten, die kennzeichnet, welche Architektur-Features angenommen wurde, wenn der Geräte-Maschinencode 344 und der virtuelle Geräte-Assembler 346 erzeugt wurden. Fachleute werden erkennen, dass die Funktionen, die innerhalb des Geräte-Maschinencodes 344 und virtuellen Assemblers 346 enthalten sind, Funktionen Wiederspiegeln (engl. „reflect”), die mit der tatsächlichen Architektur der PPU 202 assoziiert sind. Die Architekturinformation 348 stellt Kompatibilitätsinformation für den Geräte-Maschinencode 344 und Compilerhinweise für eine Kompilierungsoperation zweiter Stufe bereit, die zu irgendeinem Zeitpunkt, nachdem die Entwicklung der Coprozessor-geeigneten Anwendung 134 schon beendet wurde, von einem Gerätetreiber 103 ausgeführt werden mögen.
-
Der Geräte-Compiler-und-Linker 324 ist auch dazu konfiguriert, verschiedene Optimierungsroutinen mit dem Programmcode 310 auszuführen. Eine solche Optimierungsroutine beinhaltet ein wahlweises Rematerialisieren von Sätzen bzw. Mengen von Live-in-Variablen, wie es unten im Zusammenhang mit der 4 detaillierter beschrieben wird.
-
Live Analyse-basierte Rematerialisation
-
4 ist ein Flussdiagram von Verfahrensschritten zur Ausführung von live Analyse-basierter Rematerialisation mit einer Menge von Live-in-Variablen, gemäß einer Ausführungsform der vorliegenden Erfindung. Obwohl die Verfahrensschritte im Zusammenhang mit den Systemen von den 1–2 beschrieben werden, werden Fachleute verstehen, dass jedes System, das konfiguriert ist zum Ausführen der Verfahrensschritte, in jeglicher Reihenfolge, im Umfang der vorliegenden Erfindung enthalten ist. In einer Ausführungsform mag der in 3 gezeigte Geräte-Compiler-und-Linker 324 zum Durchführen der Verfahrensschritte konfiguriert sein.
-
Ein Verfahren 400 beginnt, wie gezeigt, bei Schritt 402, wo der Geräte-Compiler-und-Linker 324 einen Kontrollflussgraphen für den Programmcode 310 erzeugt. Der Kontrollflussgraph, der von dem Geräte-Compiler-und-Linker 324 erzeugt wird, mag ein konventioneller Kontrollgraph (engl. „control graph”) sein, der unter Verwendung von Flussanalysetechniken erzeugt wird, und mag als solche eine Sammlung von Codeblöcken enthalten. Bei Schritt 404 identifiziert der Geräte-Compiler-und-Linker 324 einen Block in dem Kontrollflussgraphen, welcher Block eine maximale Anzahl von Live-in-Variablen enthält. In einer Ausführungsform bestimmt der Geräte-Compiler-und-Linker 324 die Anzahl von Live-in-Variablen für jeden Block in dem Kontrollflussgraphen und identifiziert dann der Block, der die größte Anzahl von Live-in-Variablen hat. Die maximale Anzahl von Live-in-Variablen wird von einem Wert dargestellt, der als „Max-Live-in” bezeichnet wird. Max-Live-in mag eine Größe von Registerdruck angeben, der durch Ausführung der Coprozessor-geeigneten Anwendung 134 verursacht wird. Bei Schritt 406 sammelt der Geräte-Compiler-und-Linker 324 Live-in-Variable, die mit dem Block assoziiert sind, der beim Schritt 404 identifiziert wurde.
-
Bei Schritt 408 wählt der Geräte-Compiler-und-Linker 324 eine Teilmenge der Live-in-Variable für Rematerialisation aus, basierend auf einer Ausführung einer Profitabilitätsanalyse mit verschiedenen Teilmengen von Live-in-Variablen. Der Geräte-Compiler-und-Linker 324 mag die Profitabilitätsanalyse durchführen, um die „Profitabilität” einer Rematerialisation von einer gegebenen Teilmenge von Live-in-Variablen zu bestimmen. Die „Profitabilität” von einer gegebenen Teilmenge von Live-in-Variablen mag ein numerischer Wert sein, der die Anzahl von Live-in-Variablen wiederspiegelt, die durch Rematerialisation der gegebenen Teilmenge reduziert wurde. Dieser Wert mag des Weiteren die Anzahl von Befehlen, die für diese Rematerialisation hineingezogen wurden, und/oder die maximale Anzahl von Registern, die für jeden Thread erlaubt sind, Wiederspiegeln, wie es unten in Zusammenhang mit der 5 detaillierter beschrieben wird.
-
Bei Schritt 410 rematerialisiert der Geräte-Compiler-und-Linker 324 die Live-in-Variablen in der gegebenen Teilmenge. Der Geräte-Compiler-und-Linker 324 mag jede technisch realisierbare Rematerialisationstechnik implementieren. In einer Ausführungsform rematerialisiert der Geräte-Compiler-und-Linker 324 eine gegebene Teilmenge von Live-in-Variablen dadurch, dass er erst Berechnungen, die diese Live-in-Variable einbeziehen, von einem Block des Kontrollflussgraphen entfernt. Der Geräte-Compiler-und-Linker 324 mag dann einen nachfolgenden Block des Kontrollflussgraphen modifizieren, um die Live-in-Variable, die mit der Teilmenge innerhalb des nachfolgenden Blocks assoziiert sind, erneut zu berechnen (engl. „re-compute”). Dabei mag der Geräte-Compiler-und-Linker 324 den Programmcode 310 nach Bedarf modifizieren. Bei Schritt 412 aktualisiert der Geräte-Compiler-und-Linker 324 Max-Live-in durch Identifizieren der Anzahl von Live-in-Variablen für jeden Block und Identifizieren des Blocks mit der größten Anzahl von Live-in-Variablen. Dann endet das Verfahren 400.
-
Der Geräte-Compiler-und-Linker 324 mag die Schritte 404, 406, 408, 410 und 412 bis zum Erreichen eines spezifischen Ziels iterativ ausführen. In einer Ausführungsform führt der Geräte-Compiler-und-Linker 324 diese Schritte eine feste Anzahl von Malen durch, zum Beispiel fünfmal. In einer anderen Ausführungsform führt der Geräte-Compiler-und-Linker 324 die Schritte 404, 406, 408, 410 und 412 iterativ durch, bis Max-Live-in auf einen Wert unterhalb eines gegebenen Schwellenwerts abfällt, was darauf hinweist, dass der Registerdruck als Folge der Rematerialisation ausreichend abgenommen hat.
-
5 ist ein Flussdiagramm von Verfahrensschritten zur Ausführung einer Profitabilitätsanalyse auf einer Menge von Live-in-Variablen, gemäß einer Ausführungsform der Erfindung. Obwohl die Verfahrensschritte im Zusammenhang mit den Systemen von den 1–2 beschrieben werden, werden Fachleute verstehen, dass jedes System, das konfiguriert ist zum Ausführen der Verfahrensschritte, in jeglicher Reihenfolge, im Umfang der vorliegenden Erfindung enthalten ist. In einer Ausführungsform mag der in 3 gezeigte Geräte-Compiler-und-Linker 324 konfiguriert sein zum Implementieren der Verfahrensschritte mit einer Teilmenge von Live-in-Variablen, die mit dem Block assoziiert sind, der im Schritt 404 von dem Verfahren 400 identifiziert wurde.
-
Das Verfahren 500 beginnt, wie gezeigt, bei Schritt 502, bei dem der Geräte-Compiler-und-Linker 324 einen ersten Profitabilitätsfaktor für die Teilmenge von Live-in-Variablen erzeugt basierend auf der Anzahl von Live-in-Variablen, die mittels Rematerialisation reduziert worden ist. Der Geräte-Compiler-und-Linker 324 könnte zum Beispiel feststellen, dass eine Rematerialisation die Anzahl von Live-in-Variablen mit zwei reduziert und diese Zahl mit eins erhöht, für einen Nettoverlust von einer Live-in-Variable.
-
Bei Schritt 504 erzeugt der Geräte-Compiler-und-Linker 324 einen zweiten Profitabilitätsfaktor basierend auf den Anzahl von Befehlen, die für die Rematerialisation hineingezogen worden ist, und den Kosten für die Einsatzstellen (engl. „use-sites”), die von der Rematerialisation erfordert werden. Da verschiedene Live-in-Variablen mit Befehlen unterschiedlicher Komplexität und/oder mit Einsatzstellen, die unterschiedlichen Kosten haben, assoziiert werden mögen, erzeugt der Geräte-Compiler-und-Linker 324 den zweiten Profitabilitätsfaktor, um solche Unterschiede zwischen verschiedenen Teilmengen von Live-in-Variablen zu quantifizieren.
-
Bei Schritt 506 erzeugt der Geräte-Compiler-und-Linker 324 einen dritten Profitabilitätsfaktor basierend auf der maximalen Anzahl von Registern, die für jeden Thread erlaubt ist, der zum Ausführen der Coprozessor-geeigneten Anwendung 134 konfiguriert ist. Dabei mag der Geräte-Compiler-und-Linker 324 die Kosten schätzen, die mit einem „Überlauf”-Ereignis verbunden sind, das eintreffen würde, wenn die maximale Anzahl von Registern überschritten wird. Die Kosten könnten zum Beispiel unter anderem eine Erhöhung der Speicherlatenz als Folge des Überlauf-Ereignisses und/oder eine Verringerung in Programmausführungsgeschwindigkeit wiederspiegeln. Bei Schritt 508 schätzt der Geräte-Compiler-und-Linker 324 die Profitabilität einer Rematerialisation der Teilmenge von Live-in-Variablen basierend auf den ersten, zweiten und dritten Profitabilitätsfaktor, die jeweils in den Schritten 402, 404 und 406 erzeugt wurden. Die „Profitabilität” von einer Rematerialisation einer gegebenen Teilmenge von Live-in-Variablen ist generell ein numerischer Wert, der den potentiellen Gewinn von einer Rematerialisation dieser Teilmenge von Variablen wiederspiegelt.
-
Der Geräte-Compiler-und-Linker 324 ist dazu konfiguriert, das Verfahren 500 mit mehreren verschiedenen Teilmengen von der Menge von Live-in-Variablen durchzuführen, die mit dem beim Schritt 404 des Verfahrens 400 identifizierten Block assoziiert sind. Dabei mag der Geräte-Compiler-und-Linker 324 die Profitabilität einer Rematerialisation jeder möglichen Teilmenge von diesen Live-in-Variablen schätzen und dann diejenige Teilmenge für Rematerialisation auswählen, die die größte Profitabilität hat.
-
Die Verfahren 400 und 500, die oben im Zusammenhang mit den 4 und 5 beschrieben wurden, werden unten detaillierter anhand eines Beispiels in Zusammenhang mit der 6 dargestellt.
-
6 legt einen beispielhaften Kontrollflussgraph dar zur Illustration der Operation eines Geräte-Compiler-und-Linker, gemäß einer Ausführungsform der vorliegenden Erfindung. Der Geräte-Compiler-und-Linker 324 mag den Kontrollflussgraphen 600 basierend auf dem Programmcode 310 beim Schritt 402 des Verfahrens 400 erzeugen, wie es oben im Zusammenhang mit der 4 beschrieben wurde. Der Kontrollflussgraph 600 enthält, wie gezeigt, die Blöcke 610 und 620. Der Block 610 enthält zwei Ausdrücke und erhält eine Live-in-Variable „t” von einem früheren bzw. vorhergehenden (nicht gezeigten) Block. Der Block 620 enthält drei Ausdrücke und erhält zwei Live-in-Variable „x” und ”y” von dem Block 610. Die Ausdrücke innerhalb dieser Blöcke werden von dem Programmcode 310 abgeleitet (engl. „derived”). In dem folgenden Beispiel führt der Geräte-Compiler-und-Linker 324 die Verfahren 400 und 500 durch, die oben jeweils in Zusammenhang mit den 4 und 5 beschrieben wurden, um Variable innerhalb des Kontrollflussgraphen 600 wahlweise zu rematerialisieren. Dabei mag der Geräte-Compiler-und-Linker 324 den Registerdruck reduzieren, wenn eine gegebene PPU 202 Code ausführt, der von dem Kontrollflussgraphen 600 dargestellt ist.
-
Wenn der Geräte-Compiler-und-Linker 324 den Kontrollflussgraphen 600 erzeugt hat, identifiziert der Geräte-Compiler-und-Linker 324 den Block innerhalb des Kontrollflussgraphen 600, der die maximale Anzahl von Live-in-Variablen aufweist. Da der Block 610 eine Live-in-Variable erhält und der Block 620 zwei Live-in-Variable erhält, identifiziert der Geräte-Compiler-und-Linker 324 den Block 620 als Max-Live-in habend, ähnlich dem Schritt 404 des Verfahrens 400. Der Geräte-Compiler-und-Linker 324 wählt dann eine Teilmenge von Live-in-Variablen aus, die mit dem Block 620 assoziiert sind, basierend auf einer Profitabilitätsanalyse, die mit jeder mögliche Teilmenge durchgeführt wird.
-
In diesem Beispiel könnte der Geräte-Compiler-und-Linker 324 die Profitabilitätsanalyse mit Teilmengen durchführen, die die Live-in-Variable „x”, die Live-in-Variable „y” oder die beide Live-in-Variable „x” und „y” enthalten. Die Profitabilitätsanalyse, die in Zusammenhang mit der 5 skizziert wurde, würde zeigen, dass eine unabhängige Rematerialisation von nur „x” oder „y” die Anzahl der Live-in-Variable zu Block 620 nicht reduzieren würde, da dies „t” als eine neue Live-in-Variable einführen würde, für einen Nettoverlust von null Live-in-Variablen. Rematerialisation von sowohl „x” als auch „y” zusammen würde aber die Anzahl von Live-in-Variablen mit zwei reduzieren und die Anzahl von Live-in-Variablen nur mit eins erhöhen, für einen Nettoverlust von einer Live-in-Variable. Dieser Nettoverlust mag in dem ersten Profitabilitätsfaktor wiederspiegelt werden, der von dem Geräte-Compiler-und-Linker 324 im Schritt 502 des Verfahrens 500 für die Teilmenge, die „x” und „y” enthält, erzeugt wurde.
-
Der Geräte-Compiler-und-Linker 324 ist auch konfiguriert zum Bestimmen der Anzahl von Befehlen, die für Rematerialisation von Live-in-Variablen in einer gegebenen Teilmenge eingezogen worden sind, und zum Bestimmen der Kosten für die Einsatzstellen, die zur Rematerialisation von diesen Live-in-Variablen benötigt werden, ähnlich dem Schritt 504 des Verfahrens 500. In diesem Beispiel würde der Geräte-Compiler-und-Linker 324 die Definitionen der Live-in-Variablen „x” und „y” sowie die Art von Speicherzugriffen, die von diesen Definitionen benötigt werden, analysieren, um den „Aufwand” (engl. „overhead”) zu erfassen, der mit der Rematerialisation von diesen Variablen verbunden ist. In einigen Fällen mag der Aufwand, der mit der Rematerialisation von den Live-in-Variablen in einer gegebenen Teilmenge verbunden ist, untragbar sein, zum Beispiel wegen der Komplexität der Befehle, die zur Rematerialisation bestimmter Live-in-Variable benötigt werden, oder der Einsatzstellenkosten, die mit der Rematerialisation dieser Variable assoziiert sind. Der zweite Profitabilitätsfaktor, der von dem Geräte-Compiler-und-Linker 324 beim Schritt 504 des Verfahrens 500 erzeugt wurde, wiederspiegelt im Allgemeinen diesen Aufwand.
-
Für jede Teilmenge von Live-in-Variablen, die in diesem Beispiel diskutiert wird, insbesondere die Teilmengen, die „x”, „y” oder „x” und „y” enthalten, erzeugt der Geräte-Compiler-und-Linker 324 den ersten und den zweiten Profitabilitätsfaktor, die oben und jeweils in Zusammenhang mit den Schritten 502 und 504 des Verfahrens 500 behandelt wurden. Für jede solche Teilmenge erzeugt der Geräte-Compiler-und-Linker 324 auch den dritten Profitabilitätsfaktor, der in Zusammenhang mit dem Schritt 506 des Verfahrens 500 behandelt wurde. Der Geräte-Compiler-und-Linker 324 erzeugt den dritten Profitabilitätsfaktor für eine gegebene Teilmenge basierend auf der maximalen Anzahl von Registern, die für jeden Thread erlaubt ist, der zum Ausführen der Coprozessor-geeigneten Anwendung 134 konfiguriert ist, und basierend auf den mit einem „Überlauf”-Ereignis verbundenen Kosten, das stattfinden würde, wenn diese Anzahl von Registern überschritten wird. In einer solchen Situation könnten die Live-in-Variablen in der gegebenen Teilmenge in den Systemspeicher hinein überlaufen. Der Geräte-Compiler-und-Linker 324 schätzt den dritten Profitabilitätsfaktor für die gegebene Teilmenge basierend auf den Kosten eines solchen Überlaufs, zum Beispiel die Erhöhung der Speicherlatenz für die gegebene Teilmenge und/oder die Verringerung in Programmausführungsgeschwindigkeit. Der dritte Profitabilitätsfaktor, der für eine gegebene Teilmenge von Live-in-Variablen erzeugt wurde, stellt folglich ein Maß der „Risiko” dar, die mit der Rematerialisation der Live-in-Variable in dieser Teilmenge assoziiert ist.
-
Der Geräte-Compiler-und-Linker 324 schätzt die gesamte Profitabilität von einer Rematerialisation der Live-in-Variablen in den verschiedenen Teilmengen, die in diesem Beispiel diskutiert werden, basierend auf den drei Profitabilitätsfaktoren, die für jede Teilmenge erzeugt wurde, ähnlich dem Schritt 508 des Verfahrens 500. Der Geräte-Compiler-und-Linker 324 rematerialisiert dann die Live-in-Variablen in der Teilmenge, die die größte Profitabilität hat. In diesem Beispiel hat die Teilmenge, die sowohl „x” als auch „y” enthält, die größte Profitabilität, und folglich rematerialisiert der Geräte-Compiler-und-Linker diese Variable innerhalb des Blocks 620 durch Modifizieren des Programmcodes 310.
-
Zusammenfassend ist ein Geräte-Compiler-und-Linker innerhalb einer Parallelverarbeitungseinheit (PPU) konfiguriert zum Optimieren eines Programmcodes einer Coprozessor-geeigneten Anwendung durch Rematerialisation einer Teilmenge von Live-in-Variablen für einen bestimmten Block in einem Kontrollflussgraphen, der für diesen Programmcode erzeugt worden ist. Der Geräte-Compiler-und-Linker identifiziert den Block des Kontrollflussgraphen, welcher Block die größte Anzahl von Live-in-Variablen hat, und wählt dann eine Teilmenge von den Live-in-Variablen aus, die mit dem identifizierten Block assoziiert sind, für den eine Rematerialisation die größte geschätzte Profitabilität gewährt. Die Profitabilität einer Rematerialisation von einer gegebenen Teilmenge von Live-in-Variablen wird basierend auf der Anzahl von reduzierten Live-in-Variablen, den Kosten der Rematerialisation und der potentiellen Risiko bestimmt, der mit der Rematerialisation verbunden ist.
-
Rematerialisation von bestimmten Teilmengen von Live-in-Variablen reduziert vorteilhafterweise den Registerdruck, wodurch die Wahrscheinlichkeit eines Überlaufereignisses reduziert wird. Das Reduzieren des Registerdrucks erlaubt auch, dass eine größere Anzahl von Ausführungsthreads mit der PPU simultan ausgeführt wird, wodurch den gesamten Verarbeitungsdurchsatz der PPU erhöht wird.
-
Eine Ausführungsform der Erfindung mag als ein Programmprodukt zur Verwendung mit einem Computersystem implementiert werden. Das Programm bzw. die Programme des Programmprodukts definiert bzw. definieren Funktionen der Ausführungsformen (einschließlich der hierin beschriebenen Verfahren) und kann bzw. können auf einer Vielfalt von computerlesbaren Speichermedien enthalten werden. Beispielhafte computerlesbare Speichermedien umfassen, sind aber nicht darauf begrenzt: (i) nicht-schreibbare Speichermedien (zum Beispiel schreibgeschützte (engl. „read-only”) Speichervorrichtungen innerhalb eines Computers, wie zum Beispiel CD-ROM-Discs, die mittels eines CD-ROM-Laufwerks lesbar sind, Flash-Speicher, ROM-Chips oder jede andere Art von nicht-flüchtigem Festkörper-Halbleiterspeicher (engl. „solid-state non-volatile semiconductor memory”)), auf welchen Informationen permanent gespeichert werden; und (ii) schreibbare Speichermedien (zum Beispiel Floppy-Disks in einem Diskettenlaufwerk oder Festplattenlaufwerk oder jede Art von Festkörper-Halbleiterspeicher mit wahlfreiem Zugriff (engl. „solid-state random-access semiconductor memory”)), auf welchem veränderbare Informationen gespeichert sind.
-
Die Erfindung ist mit Bezug auf spezifische Ausführungsformen oben beschrieben worden. Fachleute werden aber verstehen, dass verschiedene Modifikationen und Änderungen davon gemacht werden können, ohne von dem breiteren Geist und Umfang der Erfindung, wie sie in den angehängten Patentansprüchen dargestellt ist, abzuweichen. Die vorhergehenden Beschreibung und Zeichnungen sind folglich eher in einer illustrativen als in einer restriktiven Bedeutung zu beachten.
