DE102019112301A1 - Befehls-Cache in einem Multithread-Prozessor - Google Patents

Befehls-Cache in einem Multithread-Prozessor Download PDF

Info

Publication number
DE102019112301A1
DE102019112301A1 DE102019112301.1A DE102019112301A DE102019112301A1 DE 102019112301 A1 DE102019112301 A1 DE 102019112301A1 DE 102019112301 A DE102019112301 A DE 102019112301A DE 102019112301 A1 DE102019112301 A1 DE 102019112301A1
Authority
DE
Germany
Prior art keywords
threads
thread
code
instruction
cache
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102019112301.1A
Other languages
English (en)
Inventor
Alan Graham Alexander
Simon Christian Knowles
Mrudula Gore
Jonathan Louis Ferguson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Graphcore Ltd
Original Assignee
Graphcore Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Graphcore Ltd filed Critical Graphcore Ltd
Publication of DE102019112301A1 publication Critical patent/DE102019112301A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3802—Instruction prefetching
    • G06F9/3814—Implementation provisions of instruction buffers, e.g. prefetch buffer; banks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3005—Arrangements for executing specific machine instructions to perform operations for flow control
    • G06F9/30065—Loop control instructions; iterative instructions, e.g. LOOP, REPEAT
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/084—Multiuser, multiprocessor or multiprocessing cache systems with a shared cache
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0842—Multiuser, multiprocessor or multiprocessing cache systems for multiprocessing or multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0875—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with dedicated cache, e.g. instruction or stack
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/3004—Arrangements for executing specific machine instructions to perform operations on memory
    • G06F9/30047—Prefetch instructions; cache control instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3802—Instruction prefetching
    • G06F9/3808—Instruction prefetching for instruction reuse, e.g. trace cache, branch target cache
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3802—Instruction prefetching
    • G06F9/3808—Instruction prefetching for instruction reuse, e.g. trace cache, branch target cache
    • G06F9/381—Loop buffering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline, look ahead
    • G06F9/3867—Concurrent instruction execution, e.g. pipeline, look ahead using instruction pipelines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G06F9/526—Mutual exclusion algorithms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1028—Power efficiency
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/45—Caching of specific data in cache memory
    • G06F2212/452—Instruction code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

Ein Prozessor weist auf: eine Barrelthread-Ausführungseinheit zum Ausführen von gleichzeitigen Threads und einen von den gleichzeitigen Threads gemeinsam benutzten Wiederholungs-Cache. Der Befehlssatz des Prozessors enthält einen Wiederholungsbefeh, der einen Wiederholungszahl-Operanden nimmt. Wenn der Wiederholungs-Cache nicht beansprucht wird und der Wiederholungsbefehl in einem ersten Thread ausgeführt wird, wird ein Teil des Codes vom ersten Thread in den Wiederholungs-Cache zwischengespeichert, wird der Status des Wiederholungs-Cache in eine Protokollierung als beansprucht geändert und wird der zwischengespeicherte Code mit einer Häufigkeit ausgeführt. Wenn der Wiederholungsbefehl dann in einem weiteren Thread ausgeführt, dann wird der schon zwischengespeicherte Teil des Codes wieder mit einer entsprechenden Häufigkeit jedes Mal aus dem Wiederholungs-Cache ausgeführt. Für jeden des ersten und der weiteren Befehle bestimmt der Wiederholungszahl-Operand im jeweiligen Befehl die Häufigkeit zum Ausführen des zwischengespeicherten Codes.

Description

  • Technisches Gebiet
  • Die vorliegende Offenbarung betrifft einen Befehls-Cache zum Zwischenspeichern von Teilen eines Maschinencodes in einem Multithread-Prozessor.
  • Hintergrund
  • Es gab ein steigendes Interesse an der Entwicklung von Prozessoren für spezielle Anwendungen, wie beispielsweise Grafikprozessoren (GPUs) und digitalen Signalprozessoren (DSPs). Eine andere Art von anwendungsspezifischem Prozessor, der kürzlich Interesse geweckt hat, ist einer, der Maschinenintelligenzanwendungen gewidmet ist, vom Anmelder „IPU“ (Intelligenzprozessor) genannt. Diese können zum Beispiel eingesetzt werden als Beschleunigungsprozessoren zum Durchführen einer durch einen Host zugeteilten Arbeit, beispielsweise zum Trainieren oder Unterstützen beim Trainieren eines Wissensmodells, wie beispielsweise eines neuronalen Netzes, oder zum Durchführen oder Unterstützen beim Durchführen von Vorhersagen oder Schlussfolgerungen basierend auf einem solchen Modell.
  • Ein Maschinenintelligenzalgorithmus beruht auf dem Durchführen iterativer Updates zu einem „Wissensmodell“, das durch eine Grafik aus mehreren miteinander verbundenen Knoten dargestellt werden kann. Jeder Knoten stellt eine Funktion seiner Eingaben dar. Manche Knoten empfangen die Eingaben an die Grafik und manche empfangen Eingaben von einem oder mehreren anderen Knoten, während die Ausgabe mancher Knoten die Eingaben anderer Knoten bildet und die Ausgabe mancher Knoten die Ausgabe der Grafik bereitstellt (und in manchen Fällen ein bestimmter Knoten sogar alles davon haben kann: Eingaben in die Grafik, Ausgaben von der Grafik und Verbindungen mit anderen Knoten). Ferner wird die Funktion an jedem Knoten durch einen oder mehrere entsprechende Parameter, z.B. Gewichtungen, parametrisiert. Während einer Lernstufe ist es das Ziel, basierend auf einem Satz von empirischen Eingangsdaten Werte für die verschiedenen Parameter zu finden, sodass die Grafik insgesamt eine gewünschte Ausgabe für einen Bereich möglicher Eingaben erzeugt. In der Technik sind hierfür verschiedene Algorithmen bekannt, wie beispielsweise ein Back-Propagation-Algorithmus basierend auf einem stochastischen Gradientenabstieg. Die Parameter werden über mehrere Iterationen basierend auf den Eingangsdaten allmählich abgestimmt, um ihre Fehler zu vermindern, und so konvergiert die Grafik zu einer Lösung. In einer anschließenden Stufe kann das gelernte Modell dann benutzt werden, um für einen gegebenen speziellen Satz von Eingaben Vorhersagen für Ausgaben zu machen oder für gegebenen speziellen Satz von Ausgaben Schlussfolgerungen bezüglich der Eingaben (Ursachen) zu machen.
  • Die Implementierung jedes Knotens beinhaltet das Verarbeiten von Daten, und die Verbindungen der Grafik entsprechen den zwischen den Knoten auszutauschenden Daten. Typischerweise kann wenigstens manche der Verarbeitung jedes Knotens unabhängig von manchen oder allen anderen Knoten in der Grafik ausgeführt werden, und deshalb geben große Grafiken große Möglichkeiten für Gleichzeitigkeit und/oder Parallelismus frei.
  • Daher kann ein für Maschinenintelligenzanwendungen ausgestalteter Prozessor eine Unterstützung für eine gleichzeitige Ausführung mehrerer Programm-Threads enthalten. Diese Unterstützung weist typischerweise einen jeweiligen Satz von Kontextregistern für jeden Thread auf, wobei jeder Satz verwendet wird, um den Programmstatus (den „Kontext“) eines jeweiligen von mehreren gleichzeitig auszuführenden Threads hält. Der in den Kontextregistern eines bestimmten Threads gehaltene Programmstatus weist typischerweise einen Programmzähler für diesen Thread, ein oder mehrere Steuerstatusregister, die einen Status des Threads (z.B. pausiert, laufend, etc.) protokollieren, und mehrere Operandenregister einschließlich arithmetischer Operandenregister zum vorübergehenden Halten von Werten, gemäß denen bearbeitet werden soll und die durch arithmetische Befehle des jeweiligen Threads ausgegeben werden. Die verschiedenen gleichzeitigen Threads werden durch eine gemeinsame Ausführungspipeline vorübergehend in unterschiedlichen Ausführungszeitfenstern verschachtelt, wobei jedes Fenster nur von den Registern eines anderen der Sätze von Kontextregistern Gebrauch macht.
  • In einem anderen Ansatz kann ein für Maschinenintelligenz ausgestalteter Prozessor mehrere parallele Ausführungseinheiten aufweisen, die jeweils eine separate Pipeline aufweisen (d.h. echter Parallelismus im Gegensatz zur Gleichzeitigkeit, die Verschachteln bedeutet). Der Prozessor kann in eine Anordnung von Tiles untergliedert sein, die jeweils ihre eigene Ausführungseinheit und Speicher zur Verwendung durch diese Ausführungseinheit aufweisen, womit eine Anordnung von parallelen Verarbeitungsmodulen auf demselben Chip oder auch über mehrere Chips verteilt implementiert wird. Ein Prozessor kann auch diese Anordnung mit dem gleichzeitigen Ansatz kombinieren, d.h. um so eine Anordnung von mehreren Tiles aufzuweisen, wobei jede Tile ausgestaltet ist, um mehrere gleichzeitige Threads auszuführen.
  • Zusammenfassung
  • Es ist hier bekannt, dass Umstände auftreten können, in denen es erwünscht ist, dass mehrere verschiedene Threads denselben Code ausführen. Ein Beispiel kann in einer Maschinenlernanwendung auftreten, wo jeder Thread das Verarbeiten eines anderen Knotens durchführt. In diesem Fall ist es hier bekannt, dass manche Knoten tatsächlich manche derselben Berechnungen durchführen. Es gäbe eine Einsparung hinsichtlich Energieverbrauch, falls dieser Code nicht von den Threads aller solcher Knoten separat aus dem Speicher abgerufen werden müsste. Ähnliche Themen können in anderen Anwendungen auftreten, in denen verschiedene gleichzeitige Prozesse manche oder alle derselben Vorgänge aufweisen.
  • Gemäß einem hier offenbarten Aspekt ist ein Prozessor vorgesehen, aufweisend eine Ausführungseinheit, die ausgestaltet ist, um Instanzen von in einem Befehlssatz definierten Befehlstypen auszuführen, wobei die Ausführungseinheit eine Barrelthread-Ausführungseinheit ist, die ausgestaltet ist, um mehrere gleichzeitige Threads jeweils in einem anderen einer Wiederholungssequenz von verschachtelten Zeitfenstern auszuführen; und einen Wiederholungs-Cache mit einem zugehörigen Status, der protokolliert, ob der Wiederholungs-Cache aktuell von einem der Threads beansprucht wird oder nicht. Die im Befehlssatz definierten Befehlstypen enthalten einen Wiederholungsbefehl, der einen Wiederholungszahl-Operanden nimmt, wobei die Ausführungseinheit ausgestaltet ist, um a) einen Teil des Codes vom ersten Thread in den Wiederholungs-Cache zwischenzuspeichern, den Status in eine Protokollierung des Wiederholungs-Cache als beansprucht zu modifizieren und den Teil des Codes mit einer entsprechenden Häufigkeit auszuführen, wobei jede folgende Wiederholung aus dem Wiederholungs-Cache genommen wird, wenn der Wiederholungs-Cache gemäß dem Status aktuell nicht beansprucht wird und eine jeweilige Instanz des Wiederholungsbefehls in einem ersten der Threads ausgeführt wird, und b) den schon zwischengespeicherten Teil des Codes mit einer entsprechenden Häufigkeit jedes Mal aus dem Wiederholungs-Cache auszuführen, wenn der Wiederholungs-Cache gemäß dem Status aktuell beansprucht wird und eine weitere Instanz des Wiederholungsbefehls dann als Teil irgendeines weiteren der Threads ausgeführt wird bis der Status dann in eine Protokollierung des Wiederholungs-Cache als wieder nicht beansprucht zurückgesetzt wird. Für jeden des ersten und der weiteren Befehle bestimmt der Wiederholungszahl-Operand im jeweiligen Befehl die entsprechende Häufigkeit zum Ausführen des Teils des Codes, wobei der Wiederholungszahl-Operand irgendeinen von mehreren positiven ganzzahligen Werten für die entsprechende Häufigkeit zum Ausführen des Teils des Codes bestimmen kann.
  • So stellt der hier offenbarte Prozessor vorteilafterweise einen Mechanismus bereit, durch welchen nicht nur der erste Thread basierend auf dem Wiederholungs-Cache seinen eigenen Code mehrere Male wiederverwenden kann, sondern auch weitere Threads denselben Code wiederverwenden können, der durch den ersten Thread bereits zwischengespeichert wurde, ohne denselben Code aus dem Speicher separat abrufen zu müssen.
  • In Ausführungsformen kann der Teil des Codes ein Teil nach der Instanz des Wiederholungsbefehls im ersten Thread sein.
  • In Ausführungsformen kann der Wiederholungsbefehl einen Wiederholungsgröße-Operanden zum Bestimmen einer Größe des Teils des Codes nehmen, wobei der Teil des Codes von einem vordefinierten Punkt nach der Instanz des Wiederholungsbefehls im ersten Thread bis zu einem anschließenden Punkt, der durch den Größe-Operanden der jeweiligen Instanz des Wiederholungsbefehls im ersten Thread definiert ist, laufen kann.
  • Der Wiederholungsgröße-Operand kann die Größe in Bezug auf die Anzahl einzelner Befehle nach dem vordefinierten Punkt oder in Bezug auf eine Anzahl von Befehlsbündeln nach dem vordefinierten Punkt (jedes Bündel weist mehrere Befehle auf, z.B. zwei oder vier Befehle je Befehlsbündel) bestimmen.
  • In Ausführungsformen kann der Wiederholungszahl-Operand außerdem einen Wert von Null nehmen können, wobei der Wiederholungsbefehl die Ausführungseinheit die Ausführung des Teils des Codes im jeweiligen Thread einschließlich im Fall des ersten Threads überspringen lässt, falls die Wiederholungszahl Null ist.
  • In Ausführungsformen kann der Wiederholungsbefehl die Ausführungseinheit den Teil des Codes nur einmal ohne Wiederholung als Teil des jeweiligen Threads ausführen lassen, falls die Wiederholungszahl Eins ist.
  • In Ausführungsformen kann der Wiederholungszahl-Operand ein direkter Operand sein und/oder kann der Wiederholungsgröße-Operand ein direkter Operand sein.
  • In Ausführungsformen kann der Wiederholungszahl-Operand die jeweilige Häufigkeit zum Ausführen des Teils des Codes durch Bezugnahme auf ein Register, aus dem die jeweilige Zahl zu lesen ist, bestimmen und/oder kann der Wiederholungsgröße-Operand die Größe durch Bezugnahme auf ein Register, aus dem die Größe zu lesen ist, bestimmen.
  • In Ausführungsformen kann der Prozessor einen Hardware-Mechanismus zum automatischen Zurücksetzen des Status in eine Protokollierung des Wiederholungs-Cache als wieder nicht beansprucht, wenn wenigstens einer des ersten und der weiteren Threads die Ausführung des zwischengespeicherten Teils des Codes mit seiner entsprechenden Häufigkeit beendet hat, aufweisen.
  • In Ausführungsformen kann der Mechanismus ausgestaltet sein, um des Status automatisch zurückzusetzen, wenn der erste Thread die Ausführung des zwischengespeicherten Teils des Codes mit seiner entsprechenden Häufigkeit beendet hat.
  • Alternativ kann der Mechanismus ausgestaltet sein, um die Beanspruchung des Wiederholungs-Cache automatisch zu löschen, wenn alle ersten und weiteren Threads die Ausführung des zwischengespeicherten Teils des Codes mit ihren entsprechenden Häufigkeiten beendet haben.
  • Der Status des Wiederholungs-Cache, der protokolliert, ob er beansprucht wird, kann zum Beispiel als ein interner Status des Wiederholungs-Cache oder der Ausführungseinheit implementiert sein (ein oder mehrere Latches im inneren Schaltschema) oder alternativ kann er in einem Register in einer Registerdatei implementiert sein (z.B. eines des Kontextregister des ersten Threads oder des Supervisors - siehe unten).
  • In manchen Fällen kann es erwünscht sein, dass mehrere verschiedene Threads denselben Code ausführen, aber gemäß unterschiedlichen Daten bearbeiten. Wieder kann ein Beispiel in einer Maschinenlernanwendung auftreten. Man betrachte zum Beispiel wieder den Fall, in dem jeder Thread die Verarbeitung eines anderen Knotens durchführt. Es stellt sich heraus, dass viele Knoten tatsächlich denselben Prozess aufweisen können, aber gemäß ihren jeweiligen eigenen Eingangsdaten arbeiten, z.B. wenn die fraglichen Knoten exakt dieselbe Funktion darstellen, aber unterschiedliche Eingangsverbindungen (Flanken) in der Grafik haben.
  • Daher kann der Prozessor in Ausführungsformen mehrere Sätze von Kontextregistern aufweisen, wobei jeder Satz ausgebildet ist, um einen Programmstatus eines der gleichzeitigen Threads zu halten; und kann die Ausführungseinheit ausgestaltet sein, um als Reaktion auf den Wiederholungsbefehl in jedem der ersten und weiteren Threads denselben Teil des Codes aber gemäß einem oder mehreren jeweiligen Operandenwerten, die in einem oder mehreren des dem jeweiligen Thread eigenen jeweiligen Satz von Kontextregistern gehalten sind, bearbeitend auszuführen.
  • In Ausführungsformen können die gleichzeitigen Threads mehrere Worker-Threads aufweisen und kann die Ausführungseinheit ferner ausgebildet sein, um wenigstens manchmal ein Supervisor-Subprogramm mit wenigstens einem Supervisor-Thread zum Managen der Worker-Threads auszuführen.
  • In Ausführungsformen können die Kontextregister jeweils einen entsprechenden Satz von Kontextregistern für jeden der Worker-Threads, die gleichzeitig ausgeführt werden können, und einen zusätzlichen Satz von Kontextregistern zum Halten eines Programmstatus des Supervisor-Subprogramms aufweisen.
  • In Ausführungsformen kann das Supervisor-Subprogramm ausgebildet sein, um durch anfängliches Laufen in allen Fenstern zu beginnen und dann die Worker-Threads durch Abtreten von manchen oder allen Fenstern, in denen das Supervisor-Subprogramm anfänglich gelaufen ist, an die entsprechenden Worker-Threads zu starten.
  • In Ausführungsformen kann der Befehlssatz einen Laufbefehl enthalten, der bei Ausführung als Teil des Supervisor-Subprogramms das Fenster, in dem der Laufbefehl ausgeführt wird, an einen der Worker-Threads abtreten lässt, sodass der Worker-Thread in diesem Fenster anstelle des Supervisor-Subprogramms gestartet wird.
  • In Ausführungsformen kann der Befehlssatz einen Ausstiegsbefehl enthalten, der bei Ausführung als Teil eines der Worker-Threads das Fenster, in dem der Ausstiegsbefehl ausgeführt wird, an das Supervisor-Subprogramm zurückgeben lässt, sodass das Supervisor-Subprogramm in diesem Fenster anstelle des Worker-Threads weiterläuft.
  • In manchen Fällen können Anwendungen entstehen, wodurch Threads tatsächlich gemäß manchen derselben Operandenwerte aber auch gemäß manchen anderen Operanden, die speziell für den einzelnen Thread sind, arbeiten. Ein Beispiel wäre eine Vektor- oder Matrix-Multiplikation, die als Teil einer Faltung durchgeführt wird, wodurch der Befehl in jedem Thread einen gemeinsamen Gewichtungssatz (gemeinsam benutzt von den Threads) mit Eingangsdaten, dir speziell für den einzelnen Thread sind, multipliziert. Ein besonderes Beispiel hiervon kann in einem gefalteten neuronalen Netz auftreten, wo viele Knoten tatsächlich dieselben Gewichtungen aber mit anderen Verbindungen haben. Man betrachte zum Beispiel ein Szenario, bei dem jeder Thread ausgestaltet ist, um die Verarbeitung eines anderen entsprechenden Knotens in dem neuronalen Netz durchzuführen, wie beispielsweise ein Falten eines gemeinsamen Kernels von Gewichtungen mit jeweiligen Eingangsdaten, um eine bestimmte Funktion zu erfassen. In solchen Szenarien wäre es vorteilhaft, einen Mechanismus vorzusehen, der es einem bestimmten arithmetischen Befehl erlaubt, gemäß einer Kombination von einem oder mehreren gemeinsamen Gewichtungsoperanden, die von den Threads gemeinsam benutzt werden, und einem oder mehreren Operanden speziell für den einzelnen jeweiligen Thread zu arbeiten. Das Thema ist keineswegs spezifisch für neuronale Netze und kann in irgendeiner Anwendung entstehen, die schließlich manche gemeinsam benutzten Operandenwerte und manche thread-spezifischen Operanden benutzt.
  • Dementsprechend kann in Ausführungsformen welchem wenigstens einer der Befehle in dem Teil des Codes von einem Typ sein, der gemäß einer Kombination aus i) wenigstens einem Operandenwert aus wenigstens einem Register in dem jeweiligen Satz von Kontextregistern und ii) wenigstens einem Operandenwert aus wenigstens einem Register in einem Satz von gemeinsamen Operandenregistern, die den Worker-Threads gemeinsam sind, arbeitet.
  • In Ausführungsformen kann der Satz von gemeinsam benutzten Registerdateien so ausgestaltet sein, dass nur das Supervisor-Subprogramm einen Wert in den Satz der gemeinsamen Register schreiben kann, während die Worker-Threads nur aus dem Satz der gemeinsamen Register lesen können.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist ein Computerprogramm auf einem computerlesbaren Speicher vorgesehen, aufweisend einen Code zur Ausführung auf dem Prozessor nach einem der vorhergehenden Ansprüche, wobei der Code die Threads aufweist, von denen wenigstens manche Instanzen des Wiederholungsbefehls enthalten, die so ausgestaltet sind, dass wenigstens einer der Threads den im Wiederholungs-Cache durch einen anderen der Threads zwischengespeicherten Teil des Codes wiederverwendet.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung ist Verfahren vorgesehen, aufweisend ein Ausführen eines Programms mit den Threads auf dem Prozessor durch die Ausführungseinheit, wobei wenigstens manche der Threads Instanzen des Wiederholungsbefehls enthalten, die so ausgestaltet sind, dass wenigstens einer der Threads den im Wiederholungs-Cache durch einen anderen der Threads zwischengespeicherten Teil des Codes wiederverwendet.
  • In Ausführungsformen kann das Programm ferner ausgestaltet sein, um entsprechend irgendeiner der hier offenbarten Ausgestaltungen zu arbeiten.
  • Figurenliste
  • Zum besseren Verständnis der Ausführungsformen der vorliegenden Offenbarung und um zu zeigen, wie solche Ausführungsformen in Kraft treten können, wird nur beispielhaft auf die beiliegenden Zeichnungen Bezug genommen, in denen
    • 1 ein schematisches Blockschaltbild eines beispielhaften Multithread-Prozessors ist,
    • 2 schematisch ein Schema von verschachtelten Zeitfenstern zeigt,
    • 3 schematisch einen Supervisor-Thread und mehrere Worker-Threads zeigt, die in mehreren verschachtelten Zeitfenstern ausgeführt werden,
    • 4 ein schematisches Blockschaltbild ist, das weitere Details eines beispielhaften Prozessors gemäß den Ausführungsformen veranschaulicht,
    • 5 ein schematisches Blockschaltbild eines Prozessors mit einer Anordnung von Teilprozessoren ist,
    • 6 eine schematische Darstellung einer Grafik ist, die in einem Maschinenintelligenzalgorithmus verwendet wird, und
    • 7 ein schematisches Blockschaltbild ist, das einen beispielhaften Wiederholungs-Cache gemäß hier offenbarten Ausführungsformen zeigt.
  • Detaillierte Beschreibung von Ausführungsbeispielen
  • 1 zeigt ein Beispiel eines Prozessors 4 gemäß Ausführungsbeispielen der vorliegenden Offenbarung. Der Prozessor 4 weist eine Multithread-Verarbeitungseinheit 10 in Form einer Barrelthread-Verarbeitungseinheit und einen lokalen Speicher 11 auf (d.h. auf dem gleichen Tile im Fall einer Multitile-Anordnung oder dem gleichen Chip im Fall eines Ein-Prozessor-Chips). Eine Barrelthread-Verarbeitungseinheit ist eine Art Multithread-Verarbeitungseinheit, in welcher die Ausführungszeit der Pipeline in eine Wiederholungssequenz von verschachtelten Zeitfenstern unterteilt ist, von denen jedes durch einen gegebenen Thread belegt werden kann. Dies kann auch als simultane Ausführung bezeichnet werden, wie in Kürze in mehr Einzelheiten erläutert. Der Speicher 11 weist einen Befehlsspeicher 12 und einen Datenspeicher 22 auf (die in unterschiedlich adressierbaren Speichereinheiten oder unterschiedlichen Bereichen derselben adressierbaren Speichereinheit verwirklicht sein können). Der Befehlsspeicher 12 speichert einen durch die Verarbeitungseinheit 10 auszuführenden Maschinencode, während der Datenspeicher 22 sowohl durch den ausgeführten Code zu bearbeitende Daten als auch durch den ausgeführten Code ausgegebene Daten (z.B. als ein Ergebnis solcher Verarbeitungen) speichert.
  • Der Speicher 12 speichert mehrere verschiedene Threads eines Programms, wobei jeder Thread eine jeweilige Sequenz von Befehlen zum Durchführen einer bestimmten Aufgabe oder bestimmter Aufgaben aufweist. Man beachte, dass ein hier bezeichneter Befehl einen Maschinencodebefehl bedeutet, d.h. eine Instanz eines der grundlegenden Befehle des Befehlssatzes des Prozessors, der aus einem einzelnen Opcode und null oder mehr Operanden besteht. In Ausführungsbeispielen weist das Programm mehrere Worker-Threads und ein Supervisor-Subprogramm, das als eines oder mehrere Supervisor-Threads aufgebaut sein kann, auf. Dies wird in Kürze in mehr Einzelheiten erläutert.
  • Ein Multithread-Prozessor ist ein Prozessor, der mehrere Programm-Threads nebeneinander, typischerweise in einer simultanen Art und Weise ausführen kann. Eine simultane Ausführung bedeutet, dass die Threads eine gemeinsame Ausführungspipeline (oder wenigstens einen gemeinsamen Teil einer Pipeline) gemeinsamen nutzen und verschiedene Threads durch diese gemeinsam benutzte Ausführungspipeline in unterschiedlichen verschachtelten Zeitfenstern in einem Wiederholungszyklus verschachtelt sind. Dies erhöht die Leistungsfähigkeit wegen erhöhter Möglichkeiten zum Ausblenden einer Pipeline-Wartezeit. Der Prozessor weist eine Hardware auf, die den mehreren verschiedenen Threads gemeinsam ist (z.B. einen gemeinsamen Befehlsspeicher, Datenspeicher und/oder Ausführungseinheit), aber zum Unterstützen des Multithreadings weist der Prozessor auch eine dedizierte Hardware speziell für jeden Thread auf.
  • Die dedizierte Hardware weist einen separaten Satz von Kontextregistern 26 für wenigstens jeden der Threads auf, die simultan ausgeführt werden können, d.h. einen Satz je Fenster im Zyklus. Wenn über Multithread-Prozessoren gesprochen wird, bezieht sich ein „Kontext“ auf den Programmzustand eines jeweiligen der Threads, die nebeneinander ausgeführt werden (z.B. Programmzählerwert, Status- und aktuelle Operandenwerte). Die Kontextregister beziehen sich auf die jeweiligen Register zum Darstellen dieses Programmzustands des jeweiligen Threads. Die Register in einer Registerdatei sind von einem allgemeinen Speicher dahingehend verschieden, dass die Registeradressen als Bits in Befehlswörtern fixiert sind, während Speicheradressen durch die Ausführungsbefehle berechnet werden können.
  • In der Verarbeitungseinheit 10 können mehrere verschiedene der Threads aus dem Befehlsspeicher 12 durch eine einzelne Ausführungspipeline 13 verschachtelt werden (obwohl typischerweise nur ein Untersatz der gesamten Threads, die im Befehlsspeicher gespeichert sind, an irgendeinem Punkt im gesamten Programm verschachtelt werden kann). Die Multithread-Verarbeitungseinheit 10 weist mehrere Sätze von Kontextregistern 26 auf, wobei jeder Satz 26 ausgebildet ist, um den Zustand (Kontext) eines jeweiligen anderen der Threads, der simultan ausgeführt werden kann, darzustellen. Die Multithread-Verarbeitungseinheit 10 weist auch eine gemeinsam benutzte Ausführungspipeline 13 auf, die den simultan ausgeführten Threads gemeinsam ist, und einen Scheduler 24 zum Planen der simultanen Threads zur Ausführung durch die gemeinsam benutzte Pipeline in einer verschachtelten Weise, z.B. in einer Ringverteilungsweise. Die Verarbeitungseinheit 10 ist mit einem gemeinsam benutzten Befehlsspeicher 12, der den mehreren Threads gemeinsam ist, und einem gemeinsam benutzten Datenspeicher 22, der ebenfalls den mehreren Threads gemeinsam ist, verbunden.
  • Die Ausführungspipeline 13 weist eine Abrufstufe 14, eine Decodierstufe 16 und eine Ausführungsstufe 18 mit einer Ausführungseinheit, die arithmetische und logische Vorgänge, Adressberechnungen, Lade- und Speichervorgänge und weitere Vorgänge durchführen kann, wie sie durch die Befehlssatzarchitektur definiert sind ,auf.
  • Jeder Satz der Kontextregister 26 weist ein entsprechendes oder mehrere entsprechende Steuerregister mit wenigstens einem Programmzähler (PC) für den jeweiligen Thread (zum Nachverfolgen der Befehlsadresse, bei welcher der Thread aktuell ausgeführt wird), und in Ausführungsbeispielen auch einen Satz von einem oder mehreren Steuerstatusregistern (CSRs), die einen aktuellen Status des jeweiligen Threads aufzeichnen (beispielsweise ob er aktuell ausgeführt wird oder pausiert) auf. Jeder Satz der Kontextregisterdateien 26 weist auch einen entsprechenden Satz von Operandenregistern zum vorübergehenden Halten der Operanden der durch den jeweiligen Thread ausgeführten Befehle auf, d.h. bearbeitete Werte oder aus durch die Opcodes der jeweiligen Thread-Befehle definierten Vorgängen bei ihrer Ausführung resultierende Werte. Jeder Satz von Registern 26 kann in einer oder mehreren Registerdateien umgesetzt sein.
  • Die Abrufstufe 14 hat Zugriff auf den Programmzähler (PC) jedes der Kontexte. Für jeden jeweiligen Thread ruft die Abrufstufe 14 den nächsten Befehl dieses Threads von der nächsten Adresse im Programmspeicher 12 ab, wie sie durch den Programmzähler angegeben ist. Der Programmzähler wird automatisch nach jedem Ausführungszyklus erhöht, sofern er nicht durch einen Verzweigungsbefehl verzweigt. Die Abrufstufe 10 gibt den abgerufenen Befehl dann an die Decodierstufe 16 weiter, um decodiert zu werden, und die Decodierstufe 16 gibt dann eine Angabe des decodierten Befehls an die Ausführungseinheit 18 zusammen mit den decodierten Adressen der im Befehl bestimmten Operandenregister weiter, damit der Befehl ausgeführt wird. Die Ausführungseinheit 18 hat Zugriff auf die Operandenregister und die Steuerstatusregister, welche sie beim Ausführen des Befehls basierend auf den decodierten Registeradressen benutzen kann, wie beispielsweise im Fall eines arithmetischen Befehls (z.B. durch Addieren, Multiplizieren, Subtrahieren oder Dividieren der Werte in zwei Operandenregistern und Ausgeben des Ergebnisses an ein anderes Operandenregister des jeweiligen Threads). Oder falls der Befehl einen Speicherzugriff definiert (Laden oder Speichern), lädt die Lade/Speicher-Logik der Ausführungseinheit 18 einen Wert aus dem Datenspeicher in ein Operandenregister des jeweiligen Threads oder speichert einen Wert aus einem Operandenregister des jeweiligen Threads in den Datenspeicher 22, entsprechend dem Befehl.
  • Die Abrufstufe 14 ist so verbunden, dass sie auszuführende Befehle aus dem Befehlsspeicher 12 unter Kontrolle des Schedulers 24 abruft. Der Scheduler 24 ist ausgestaltet, um die Abrufstufe 14 zu steuern, um einen Befehl aus jedem eines Satzes von simultan ausgeführten Threads in einer Wiederholungssequenz von Zeitfenstern abzurufen, um so die Ressourcen der Pipeline 13 in mehrere zeitlich verschachtelte Zeitfenster zu unterteilen, wie in Kürze in mehr Einzelheiten erläutert. Zum Beispiel könnte das Planungsschema eine Ringverteilung oder eine gewichtete Ringverteilung sein. Ein anderer Begriff für einen in einer solchen Weise arbeitenden Prozessor ist ein Barrelthread-Prozessor.
  • Ein Beispiel des durch den Scheduler 24 verwirklichten Verschachtelungsschemas ist in 2 veranschaulicht. Hier sind die simultanen Threads gemäß einem Ringverteilungsschema verschachtelt, wodurch in jeder Runde des Schemas die Runde in eine Sequenz von Zeitfenstern S0, S1, S2...SJ-1 (z.B. J=4 oder J=6) unterteilt ist, wobei jedes Fenster dem Ausführen eines jeweiligen Threads dient. Typischerweise ist jedes Fenster einen Ausführungszyklus lang und sind die verschiedenen Fenster gleich groß, obwohl dies nicht notwendigerweise in allen Ausführungsbeispielen so ist, z.B. ist auch ein gewichtetes Ringverteilungsschema möglich, wodurch manche Threads mehr Zyklen als andere je Ausführungsrunde bekommen. Im Allgemeinen kann das Barrelthreading entweder eine gleichmäßige Ringverteilung oder einen gewichteten Ringverteilungsplan verwenden, wobei im letztgenannten Fall die Gewichtung fest oder anpassbar sein kann.
  • Was auch immer die Sequenz je Ausführungsrunde ist, dieses Muster wiederholt dann jede Runde mit einer entsprechenden Instanz jedes der Zeitfenster. Man beachte deshalb, dass ein Zeitfenster, wie es hier bezeichnet wird, den zugeordneten Wiederholungsplatz in der Sequenz bedeutet, nicht eine besondere Instanz des Zeitfensters in einer gegebenen Wiederholung der Sequenz. Oder anders gesagt teilt der Scheduler 24 die Ausführungszyklen der Pipeline 13 in mehrere zeitlich verschachtelte (Time-Division-Multiplex) Ausführungskanäle, wobei jeder eine Wiederholung eines jeweiligen Zeitfensters in einer Wiederholungssequenz der Zeitfenster aufweist. Im gezeigten Ausführungsbeispiel gibt es vier Zeitfenster, aber dies dient nur Veranschaulichungszwecken und es sind auch andere Anzahlen möglich. Z.B. gibt es in einem bevorzugten Ausführungsbeispiel tatsächlich sechs Zeitfenster.
  • In Ausführungsbeispielen weisen die Kontextregister 26 einen jeweiligen Satz von Worker-Kontextregistern CX0...CX(J-1) für jeden der Anzahl J von Threads auf, die simultan ausgeführt werden können (J=3 in dem gezeigten Beispiel, aber dies ist nicht einschränkend), und eine zusätzliche Supervisor-Kontextregisterdatei CXS. Die Worker-Kontextregisterdateien halten die Kontexte der Worker-Threads, und die Supervisor-Kontextregisterdatei hält den Kontext eines Supervisor-Threads. Man beachte, dass in Ausführungsbeispielen der Supervisor-Kontext eine andere Anzahl an Registern als jeder der Worker haben kann. Die Verarbeitungseinheit 10 weist so eine Kontextregisterdatei 26 mehr auf als es Zeitfenster gibt, d.h. sie unterstützt einen Kontext mehr als die Anzahl verschachtelter Zeitfenster ein Barrelthreading machen kann.
  • Jeder der Worker-Kontexte CX0...CXJ-1 wird benutzt, um den Status eines jeweiligen von mehreren Worker-Threads darzustellen, die aktuell einem der J (z.B. vier) Ausführungszeitfenster S0...SJ-1 zum Durchführen von anwendungsspezifischen Berechnungsaufgaben, welche auch immer vom Programmierer gewünscht sind, zugeordnet ist (man beachte wieder, dass dies nur ein Teilsatz der Gesamtzahl der Worker-Threads des Programms sein kann, wie es im Befehlsspeicher 12 gespeichert ist). Der zusätzliche Kontext CXS wird benutzt, um den Zustand eines „Supervisor-Thread“ (SV) darzustellen, dessen Rolle es ist, die Ausführung der Worker-Threads zu koordinieren, zumindest im Sinne einer Zuordnung, welcher der Worker-Threads W in welchem der Zeitfenster S0, S1, S2... an irgendeinem Punkt im gesamten Programm ausgeführt werden soll. Optional kann der Supervisor-Thread einen weiteren „Aufpasser“ oder Koordinationszuständigkeiten wie beispielsweise ein Durchführen externer Wechsel oder Grenzsynchronisationen haben. Man beachte natürlich, dass der gezeigte Fall von J=4 nur eine beispielhafte Umsetzung zu Veranschaulichungszwecken ist. Z.B. ist in einer anderen Umsetzung J=6 (sechs Zeitfenster, sechs Worker-Kontexte und ein Supervisor-Kontext).
  • Bezugnehmend auf 3 hat der Supervisor-Thread SV in Ausführungsbeispielen kein eigenes Zeitfenster für sich im Schema der verschachtelten Ausführungszeitfenster. Auch nicht die Worker, da eine Zuordnung von Fenster zu Worker-Threads flexibel definiert ist. Vielmehr hat jedes Zeitfenster seinen eigenen Satz von Kontextregistern zum Speichern von Worker-Kontext, der vom Worker verwendet wird, wenn das Fenster dem Worker zugeordnet wird, aber nicht benutzt wird, wenn das Fenster dem Supervisor zugeordnet wird. Wenn ein gegebenes Fenster dem Supervisor zugeordnet wird, benutzt dieses Fenster stattdessen die Kontextregisterdatei CXS des Supervisors. Der Supervisor hat immer Zugriff auf seinen eigenen Kontext und keine Worker können die Supervisor-Kontextregisterdatei CXS besetzen.
  • Der Supervisor-Thread SV hat die Fähigkeit, in irgendeinem und allen der Zeitfenster S0...S3 (oder allgemeiner S0...SJ-1) zu laufen. Der Scheduler 24 ist ausgestaltet, um beim Starten des Programms als Ganzes durch Zuordnen des Supervisor-Threads zu allen Zeitfenstern zu beginnen, d.h. der Supervisor SV beginnt in allen von S0...SJ-1 zu laufen. Der Supervisor-Thread ist jedoch mit einem Mechanismus versehen, um an irgendeinem folgenden Punkt (entweder sofort oder nach dem Durchführen einer oder mehrerer Supervisor-Aufgaben) vorübergehend jedes der Fenster, in dem er läuft, an einen entsprechenden der Worker-Threads abzutreten, z.B. anfängliche Worker W0...W3 in dem in 3 gezeigten Beispiel (oder allgemeiner W0...WJ-1). Dies wird erreicht, indem der Supervisor-Thread einen Lauf-Befehl ausführt, der wenigstens eine Adresse eines Worker-Threads im Befehlsspeicher 22 als einen Operanden nimmt. Die Worker-Threads sind Teile des Codes, der simultan mit einem anderen laufen kann, wobei jeder eine oder mehrere entsprechende durchzuführende Berechnungsaufgaben darstellt.
  • Der Lauf-Befehl wirkt auf den Scheduler 24 so, dass er das aktuelle Zeitfenster, in dem dieser Befehl selbst ausgeführt wird, an den durch den Operanden bestimmten Worker-Thread abtritt. Man beachte, dass es im Lauf-Befehl impliziert ist, dass es das Zeitfenster ist, in dem dieser Befehl ausgeführt wird, welches abgetreten wird (impliziert im Kontext von Maschinencodebefehlen bedeutet, dass es keines Operanden bedarf, um dies zu bestimmen - es ist impliziert aus dem Opcode selbst zu verstehen). Somit ist das Zeitfenster, das weggegeben wird, das Zeitfenster, in dem der Supervisor den Lauf-Befehl ausführt.
  • Der Supervisor-Thread SV führt einen ähnlichen Vorgang in jedem des einen oder der mehreren anderen Zeitfenster durch, um einige oder alle seiner Zeitfenster an verschiedene entsprechende Worker-Threads W0...WJ-1 (ausgewählt aus einem größeren Satz von möglichen Worker-Threads im Befehlsspeicher 12) abzugeben. Wenn dies einmal für das letzte Fenster erfolgt ist, wird der Supervisor gesperrt (dann später wieder fortgesetzt, wo er aufhörte, wenn eines der Fenster durch einen Worker W zurückgegeben wird). Der Supervisor-Thread SV ist somit in der Lage, verschiedene Worker-Threads, die jeweils eine oder mehrere Aufgaben durchführen, an verschiedene der verschachtelten Ausführungszeitfenster S0...SJ-1 (z.B. J=4, wie dargestellt, oder J=6) zuzuordnen. Wenn der Supervisor-Thread bestimmt, dass es Zeit ist, einen Worker-Thread auszuführen, benutzt er den Lauf-Befehl, um diesen Worker dem Zeitfenster zuzuordnen, in dem der Lauf-Befehl ausgeführt wurde.
  • In manchen Ausführungsbeispielen weist der Befehlssatz auch eine Variante des Lauf-Befehls, „alle laufen“ auf. Dieser Befehl wird benutzt, um einen Satz von mehr als einem Worker zusammen zu starten, die alle den gleichen Code ausführen. In Ausführungsbeispielen startet dies einen Worker in jedem der Fenster S0...S3 (oder allgemeiner S0...S(J-1)) der Verarbeitungseinheit.
  • Einmal gestartet, schreitet jeder der aktuell zugeordneten Worker-Threads W0...WJ-1 fort, um die eine oder mehreren Berechnungsaufgaben durchzuführen, die in dem durch den jeweiligen Lauf-Befehl bestimmten Code definiert sind. Am Ende davon gibt der jeweilige Worker-Thread dann das Zeitfenster, in dem er gelaufen ist, zurück an den Supervisor-Thread. Dies wird durch Ausführen eines Ausstiegsbefehls im jeweiligen Worker-Thread erzielt. Der Ausstiegsbefehl wirkt auf den Scheduler 24 so, dass er das aktuelle Zeitfenster, in dem dieser Befehl selbst ausgeführt wird, an den Supervisor-Thread zurückleitet. Als Reaktion setzt der Scheduler 24 dann das Laufen des Supervisors in diesem Fenster fort.
  • 4 zeigt weitere beispielhafte Details des Prozessors 4 einschließlich Einzelheiten der Ausführungseinheit 18 und der Kontextregister 26. Die Kontextregister 26 weisen eine jeweilige Hauptregisterdatei (MRF) 26M für jeden der M Worker-Kontexte und den Supervisor-Kontext auf. Die Kontextregister weisen ferner eine jeweilige Zusatzregisterdatei (ARF) 26A für wenigstens jeden der Worker-Kontexte auf. Die Kontextregister 26 weisen ferner eine gemeinsame Gewichtungsregisterdatei (WRF) 26W auf, auf die alle aktuell ausführenden Worker-Threads zugreifen können, um daraus zu lesen. Die WRF kann mit dem Supervisor-Kontext dahingehend in Verbindung stehen, dass der Supervisor-Thread der einzige Thread ist, der in die WRF schreiben kann. Die Kontextregister 26 können auch eine jeweilige Gruppe von Steuerstatusregistern für jeden der Supervisor- und Worker-Kontexte aufweisen (nicht dargestellt). Die Ausführungseinheit 18 weist eine Lade/Speicher-Einheit (LSU) 55, eine arithmetische Ganzzahl-Logikeinheit (IALU) 56 und eine arithmetische Gleitkommaeinheit (FPU) auf.
  • In jedem der J verschachtelten Zeitfenster S0...SJ-1 steuert der Scheduler 24 die Abrufstufe 14, um wenigstens einen Befehl eines jeweiligen Threads aus dem Befehlsspeicher 11 in den jeweiligen der J Befehlspuffer 53 (nicht dargestellt) entsprechend dem aktuellen Zeitfenster abzurufen. In Ausführungsbeispielen ist jedes Zeitfenster ein Ausführungszyklus des Prozessors, auch wenn andere Schemata nicht ausgeschlossen sind (z.B. gewichtete Ringverteilung). In jedem Ausführungszyklus des Prozessors 4 (d.h. jedem Zyklus des Prozessortakts, der den Programmzähler taktet) ruft die Abrufstufe 14 abhängig von der Anwendung entweder einen einzelnen Befehl oder ein kleines „Befehlsbündel“ (z.B. ein Zwei-Befehle-Bündel oder Vier-Befehle-Bündel) ab. Jeder Befehl wird dann über die Decodierstufe 16 in eine der LSU 55, IALU 56 oder FPU 59 ausgegeben, abhängig davon, ob der Befehl (gemäß seinem Opcode) ein Speicherzugriffsbefehl, ein arithmetischer Ganzzahlbefehl oder ein arithmetischer Gleitkommabefehl ist. In Ausführungsbeispielen führen die LSU 55 und die IALU 56 ihre Befehle mittels Registern aus der MRF 26M aus, wobei die speziellen Register in der MRF 26M durch Operanden der Befehle bestimmt sind. Die FPU 59 führt Vorgänge mittels Registern in der ARF 26A und der WRF 26W durch, wobei die speziellen Register in der ARF durch Operanden der Befehle bestimmt sind. In Ausführungsbeispielen können die Register in der WRF im Befehlstyp impliziert sein (d.h. vorbestimmt für diesen Befehlstyp).
  • Jeder Worker-Thread-Kontext hat seine eigene Instanz der Hauptregisterdatei (MRF) 26M und der Zusatzregisterdatei (ARF) 26A (d.h. eine MRF und eine ARF für jedes der Barrelthread-Fenster). Die hier bezüglich der MRF oder ARF beschriebene Funktionalität soll so verstanden werden, dass sie auf einer Basis je Kontext arbeitet. In Ausführungsbeispielen gibt es jedoch eine einzelne, gemeinsam benutzte Gewichtungsregisterdatei (WRF), die zwischen den Threads geteilt wird. Jeder Thread kann auf die MRF und die ARF nur von seinem eigenen Kontext 26 zugreifen. Alle aktuell laufenden Worker-Threads können aber auf die gemeinsame WRF zugreifen. Die WRF stellt so einen gemeinsamen Satz von Gewichtungen zur Verwendung durch alle Worker-Threads bereit. In Ausführungsbeispielen kann nur der Supervisor in die WRF schreiben und können die Worker nur aus der WRF lesen.
  • Der Befehlssatz des Prozessors 4 enthält wenigstens einen Typ von Ladebefehl, dessen Opcode bei Ausführung die LSU 55 veranlasst, Daten aus dem Datenspeicher 22 in die jeweilige ARF 26A des Threads zu laden, in dem der Ladebefehl ausgeführt wurde. Die Position des Ziels in der ARF wird durch einen Operanden des Ladebefehls bestimmt. Ein anderer Operand des Ladebefehls bestimmt ein Adressregister in der jeweiligen MRF 26M, die einen Pointer zu einer Adresse im Datenspeicher 22 hält, aus dem die Daten zu laden sind. Der Befehlssatz des Prozessors 4 enthält auch wenigstens einen Typ von Speicherbefehl, dessen Opcode bei Ausführung die LSU 55 veranlasst, Daten aus der jeweiligen ARF des Threads, in dem der Speicherbereich ausgeführt wurde, in den Datenspeicher 22 zu speichern. Die Position der Quelle des Speicherns in der ARF wird durch einen Operanden des Speicherbefehls bestimmt. Ein anderer Operand des Speicherbefehls bestimmt ein Adressregister in der MRF, der einen Pointer zu einer Adresse im Datenspeicher 22 hält, zu der die Daten zu speichern sind. Im Allgemeinen kann der Befehlssatz separate Lade- und Speicherbefehlstypen und/oder wenigstens einen Lade/Speicher-Befehlstyp, der einen oder mehrere Ladevorgänge und/oder einen oder mehrere Speichervorgänge in einem einzigen Befehl kombiniert, enthalten.
  • Der Befehlssatz des Prozessors enthält auch einen oder mehrere arithmetische Befehlstypen zum Durchführen von arithmetischen Vorgängen. Z.B. können diese enthalten: Addierbefehle, Multiplizierbefehle, Boolesche-Logik-Befehle, etc. Jeder arithmetische Befehl nimmt einen oder mehrere Quellenoperanden, die ein oder mehrere Quellenregister in einer der Registerdateien 26 des jeweiligen Threads bestimmen, und einen oder mehrere Zieloperanden, die ein oder mehrere Zielregister in einer der Registerdateien 26 des jeweiligen Threads bestimmen. Bei seiner Ausführung führt der arithmetische Befehl einen arithmetischen Vorgang gemäß einem oder mehreren Quellenoperandenwerten aus den einen oder mehreren Quellenregistern durch und platziert das Ergebnis in das Zielregister. Die/Der Quellenoperandenwert(e) wurde(n) durch einen oder mehrere vorherige Lade- oder Lade/Speicher-Befehle in das/die Quellenoperandenregister geladen. Das Ergebnis wird durch einen oder mehrere anschließende Speicher- oder Lade/Speicher-Befehle aus dem/den Zielregister(n) gesichert. Die arithmetischen Befehle enthalten vorzugsweise einen oder mehrere arithmetische Gleitkommabefehle, deren ein oder mehrere Quellenoperandenwerte Gleitkommawerte sind und deren ein oder mehrere Ergebnisse Gleitkommawerte sind. Die arithmetischen Gleitkommawerte werden durch die FPU 59 ausgeführt. In Ausführungsbeispielen ist die FPU 59 ausgestaltet, um die ARF 26A für die Quellen- und Zielregister der arithmetischen Befehle zu nutzen. D.h. es ist impliziert (vorbestimmt), dass die Quellen- und Zieloperanden eine Registerposition in der ARF bestimmen. In Ausführungsbeispielen kann der Befehlssatz auch einen oder mehrere arithmetische Ganzzahl-Befehle enthalten, die durch die IALU 56 ausgeführt werden. In Ausführungsbeispielen nutzen diese Quellen- und Zielregister in der MRF 26M.
  • Gemäß gewissen hier offenbarten Ausführungsbeispielen können die arithmetischen Gleitkommabefehle wenigstens einen Typ enthalten, der von der gemeinsamen Gewichtungsregisterdatei WRF 26W Gebrauch macht. Dieser Befehlstyp nimmt wenigstens einen Operanden, der wenigstens eine Quelle des entsprechenden arithmetischen Vorgangs in der jeweiligen ARF 26A des Threads, in dem der arithmetische Befehl ausgeführt wurde, bestimmt. Wenigstens eine andere Quelle des arithmetischen Befehls ist jedoch in der gemeinsamen WRF gemeinsam für alle Worker-Threads. Vorzugsweise ist diese Quelle in dem fraglichen arithmetischen Befehl impliziert (d.h. impliziert für diesen arithmetischen Befehlstyp). Impliziert im Sinne eines Maschinencodebefehls bedeutet, dass kein Operand für die Bestimmung erforderlich ist. D.h. in diesem Fall ist die Position der Quelle in der WRF aus dem Opcode inhärent (vorbestimmt für diesen speziellen Opcode). Als Reaktion auf den Opcode führt die FPU 59 einen arithmetischen Vorgang durch, wie er durch den Opcode bestimmt ist, der ein Arbeiten gemäß den Werten in dem/den bestimmten Quellenregister(n) in der jeweiligen ARF der Threads und dem/den implizierten Quellenregister(n) in der WRF aufweist. Sie gibt auch ein Ergebnis des arithmetischen Vorgangs an ein Zielregister in der jeweiligen ARF des Threads aus, wie er explizit durch einen Zieloperanden des arithmetischen Befehls bestimmt ist.
  • Beispiele von arithmetischen Befehlstypen, die eine implizierte Quelle in der gemeinsamen WRF 26W einsetzen können, können enthalten: eine oder mehrere Vektormultiplikations-Befehlstypen, eine oder mehrere Matrixmultiplikations-Befehlstypen, eine oder mehrere akkumulierende Vektormultiplikations-Befehlstypen und/oder akkumulierende Matrixmultiplikations-Befehlstypen (die ein Ergebnis der Multiplikation von einer Instanz des Befehls zur nächsten akkumulieren), und/oder eine oder mehrere Faltungs-Befehlstypen. Zum Beispiel kann ein Vektormultiplikations-Befehlstyp einen expliziten Eingangsvektor aus der ARF 26A mit einem vorbestimmten Gewichtungsvektor aus der WRF multiplizieren; oder ein Matrixmultiplikations-Befehlstyp kann einen expliziten Eingangsvektor aus der ARF mit einer vorbestimmten Gewichtungsmatrix aus der WRF multiplizieren. Als anderes Beispiel kann ein Faltungs-Befehlstyp eine Eingangsmatrix aus der ARF mit einer vorbestimmten Matrix aus der WRF falten. Bei einer gemeinsam benutzten Gewichtungsregisterdatei WRF, die mehreren Threads gemeinsam ist, ermöglicht sie jedem Thread, einen gemeinsamen Kernel mit seinen eigenen jeweiligen Daten zu multiplizieren oder zu falten. Dies ist nützlich, da dies ein Szenario ist, das häufig in Maschinenlernanwendungen auftritt, z.B. wenn jeder Thread einen anderen Knoten in einem neuronalen Netz darstellt und der gemeinsame Kernel eine gesuchte oder trainierte Funktion (zum Beispiel eine Kante oder eine besondere Form in einem Bereich oder Volumen von grafischen Daten) darstellt.
  • In Ausführungsbeispielen können die Werte durch den Supervisor-Thread in die WRF 26W geschrieben werden. Der Supervisor (der im Ausführungsbeispiel durch Laufen in allen Fenstern S0...SM beginnt) führt zuerst eine Reihe von Setzbefehlen aus, um die Werte mancher gemeinsamen Gewichtungen in die vorbestimmte Position in der WRF zu schreiben. Er führt dann Laufbefehle (einen Alle-Laufen-Befehl) aus, um einen entsprechenden Worker in manchen oder allen der Fenster S0...SJ-1 zu starten. Jeder Worker enthält dann eine oder mehrere Instanzen eines oder mehrerer arithmetischer Befehle des/der oben beschriebenen Typs/Typen, um so den/die entsprechenden arithmetischen Vorgang/Vorgänge an ihren eigenen jeweiligen Eingangsdaten, wie sie in ihre jeweilige ARF 26A geladen sind, aber unter Verwendung der durch den Supervisor in die WRF 26W geschriebenen gemeinsamen Gewichtungen durchzuführen. Wenn jeder Thread seine jeweilige Aufgabe beendet, führt er einen Ausstiegsbefehl aus, um sein Fenster dem Supervisor zurückzugeben. Wenn alle gestarteten Threads ihre jeweiligen Aufgaben beendet haben, kann der Supervisor neue Werte in die WRF schreiben und einen neuen Satz von Threads starten (oder einen neuen Satz starten, um die Verwendung der existierenden Werte in der WRF fortzusetzen).
  • Es sei darauf hingewiesen, dass die Begriffe „Haupt-“, „Zusatz-“ und „Gewichtungs-“ nicht notwendigerweise einschränkend sind. In Ausführungsbeispielen können sie irgendeine erste Registerdatei (je Worker-Kontext), zweite Registerdatei (je Worker-Kontext) und gemeinsam benutzte dritte Registerdatei (z.B. Teil des Supervisor-Kontextes, aber von allen Workern zugreifbar) sein. Die ARF 26A und die Zusatzausführungseinheit 18 können auch als arithmetische Registerdatei und arithmetische Ausführungsdatei bezeichnet werden, da sie für arithmetische Befehle (oder wenigstens die Gleitkomma-Arithmetik) benutzt werden. Die MRF 26M und die Zusatzausführungseinheit 18 können auch als Speicheradressen-Registerdatei und arithmetische Ausführungseinheit bezeichnet werden, da eine von ihnen zum Zugriff auf den Speicher benutzt wird. Die Gewichtungsregisterdatei WRF 26W wird so genannt, weil sie verwendet wird, um vielfache Gewichtungen zu halten, die in (einem) bestimmten arithmetischen Befehlstyp(en) benutzt werden, wie in Kürze in mehr Einzelheiten erläutert. Z.B. könnten diese benutzt werden, um die Gewichtungen von Knoten in einem neuronalen Netz darzustellen. Anders betrachtet könnte die MRF als Ganzzahl-Registerdatei bezeichnet werden, da sie benutzt wird, um Ganzzahl-Operanden zu halten, während die ARF als Gleitkomma-Registerdatei bezeichnet werden könnte, da sie benutzt wird, um Gleitkomma-Operanden zu halten. Man beachte aber, dass der Registerraum 26 in alternativen Ausführungsbeispielen nicht notwendigerweise in diese separaten Registerdateien für diese verschiedenen Zwecke unterteilt ist. Stattdessen können die durch die Haupt- und Zusatz-Ausführungseinheiten ausgeführten Befehle Register aus derselben gemeinsam benutzten Registerdatei (eine Registerdatei je Kontext im Fall eines Multithread-Prozessors) bestimmen.
  • In Ausführungsbeispielen kann der Prozessor 4 auch mit einer oder mehreren anderen Instanzen des Prozessors und/oder externen Vorrichtungen wie beispielsweise einem Netzwerkschnittstellengerät oder einem am Netzwerk angebrachten Speichergerät (NAS) verbunden sein. Wie in 5 dargestellt, kann der Prozessor 4 in Ausführungsbeispielen einen einer Anordnung 6 von miteinander verbundenen Prozessor-Tiles bilden, wobei jeder Tile einen Teil eines größeren Programms ausführt. Die einzelnen Prozessoren 4 (Tiles) bilden so einen Teil eines größeren Prozessors oder Prozessorsystems 6. Die Tiles 4 können über ein Verbindungs-Subsystem 34 zusammen verbunden sein. Die Tiles 4 können auf demselben Chip (d.h. Würfel) oder auf verschiedenen Chips oder einer Kombination (z.B. kann die Anordnung aus mehreren Chips mit jeweils mehreren Tiles 4 gebildet sein) implementiert sein. Das Verbindungssystem 34 und die Austausch-Schnittstelle 51 können deshalb dementsprechend einen internen (On-Chip-) Verbindungsmechanismus und/oder einen externen (Inter-Chip-) Austauschmechanismus aufweisen.
  • In einer beispielhaften Anwendung eines Multithread- und/oder Multitile-Prozessors oder Systems weist der Programmablauf über die mehreren Threads und/oder Tiles 4 einen Maschinenintelligenzalgorithmus auf, wie beispielsweise einen Algorithmus zum Trainieren eines neuronalen Netzes und/oder Durchführen einer Schlussfolgerung basierend auf einem neuronalen Netz. In solchen Ausführungsbeispielen wird jeder Worker-Thread oder der Teil des Programmablaufs auf jedem Tile oder jeder Worker-Thread auf jedem Tile benutzt, um einen anderen Knoten 102 in einem neuronalen Netz (einem Grafiktyp) darzustellen; und Kommunikationen zwischen Threads und/oder Tiles stellen demgemäß Flanken 104 zwischen Knoten 102 in der Grafik dar. Dies ist in 6 veranschaulicht.
  • Maschinenintelligenz beginnt mit einer Lernstufe, in der der Maschinenintelligenzalgorithmus ein Wissensmodell lernt. Das Model weist eine Grafik von miteinander verbunden Knoten (d.h. Scheitelpunkten) 102 und Flanken (d.h. Verbindungen) 104 auf. Jeder Knoten 102 in der Grafik hat eine oder mehrere Eingangsflanken und eine oder mehrere Ausgangsflanken. Manche Eingangsflanken von manchen Knoten 102 sind die Ausgangsflanken von manchen anderen Knoten, wodurch die Knoten miteinander verbunden werden, um die Grafik zu bilden. Ferner bilden ein oder mehrere Eingangsflanken eines oder mehrerer Knoten 102 die Eingänge zur Grafik in ihrer Gesamtheit und bilden eine oder mehrere Ausgangsflanken eines oder mehrerer Knoten 102 die Ausgänge der Grafik in ihrer Gesamtheit. Manchmal kann ein bestimmter Knoten auch alles haben von Eingängen in die Grafik, Ausgängen aus der Grafik und Verbindungen zu anderen Knoten. Jede Flanke 104 kommuniziert einen Wert oder häufiger einen Tensor (n-dimensionale Matrix), wobei diese die Eingaben und Ausgaben zu und von den Knoten 102 auf ihren Eingangs- bzw. Ausgangsflanken bilden.
  • Jeder Knoten 102 stellt eine Funktion seiner ein oder mehreren Eingaben dar, die von seiner/seinen Eingangsflanke(n) empfangen werden, wobei das Ergebnis dieser Funktion die an der/den Ausgangsflanke(n) bereitgestellten Ausgabe(n) ist. Jede Funktion ist durch einen oder mehrere entsprechende Parameter (manchmal als Gewichtungen bezeichnet, obwohl sie nicht unbedingt multiplikative Gewichtungen sein müssen) parametrisiert. Im Allgemeinen können die durch die verschiedenen Knoten 102 dargestellten Funktionen unterschiedliche Funktionsformen sein und/oder durch unterschiedliche Parameter parametrisiert sein.
  • Ferner ist jeder des einen oder der mehreren Parameter jeder Knotenfunktion durch einen jeweiligen Fehlerwert charakterisiert. Außerdem kann dem/den Fehler(n) in dem/den Parameter(n) jedes Knotens 102 eine jeweilige Bedingung zugeordnet sein. Für einen Knoten 102, der eine durch einen einzelnen Parameter parametrisierte Funktion darstellt, kann die Bedingung ein einfacher Grenzwert sein, d.h. die Bedingung ist erfüllt, falls der Fehler unter dem bestimmten Grenzwert liegt, aber nicht erfüllt, falls der Fehler über dem Grenzwert liegt. Für einen durch mehr als einen jeweiligen Parameter parametrisierten Knoten 102 kann die Bedingung dafür, dass dieser Knoten 102 ein akzeptables Fehlerniveau erreicht hat, komplexer sein. Zum Beispiel kann die Bedingung nur erfüllt sein, falls jeder der Parameter dieses Knotens 102 unter dem jeweiligen Grenzwert liegt. Als weiteres Beispiel kann eine kombinierte Metrik definiert sein, die die Fehler in den verschiedenen Parametern für denselben Knoten 102 kombiniert, und die Bedingung kann unter der Voraussetzung erfüllt sein, dass der Wert der kombinierten Metrik unter einem bestimmten Grenzwert liegt, aber andernfalls ist die Bedingung nicht erfüllt, falls der Wert der kombinierten Metrik über dem Grenzwert liegt (oder umgekehrt, abhängig von der Definition der Metrik). Welche Bedingung auch immer, dies gibt ein Maß dafür, ob der Fehler in dem/den Parameter(n) des Knotens unter ein bestimmtes Niveau oder Maß an Akzeptanz fällt. Allgemein kann irgendeine geeignete Metrik verwendet werden. Die Bedingung oder die Metrik können für alle Knoten gleich sein oder für verschiedene einzelne Knoten unterschiedlich sein.
  • In der Lernstufe empfängt der Algorithmus Erfahrungsdaten, d.h. mehrfache Datenpunkte, die verschiedene mögliche Kombinationen von Eingaben zur Grafik darstellen. Wenn immer mehr Erfahrungsdaten empfangen werden, passt der Algorithmus die Parameter der verschiedenen Knoten 102 in der Grafik basierend auf den Erfahrungsdaten allmählich an, um zu versuchen, die Fehler in den Parameter zu minimieren. Es ist das Ziel, Werte der Parameter zu finden, sodass die Ausgabe der Grafik so nah wie möglich an einer gewünschten Ausgabe für eine gegebene Eingabe ist. Wenn die Grafik insgesamt zu einem solchen Zustand tendiert, konvergiert die Grafik sozusagen. Nach einem geeigneten Maß an Konvergenz kann die Grafik dann benutzt werden, um Vorhersagen oder Schlussfolgerungen durchzuführen, d.h. ein Ergebnis für eine gegebene Eingabe vorherzusagen oder eine Ursache für eine gegebene Ausgabe schlusszufolgern.
  • Die Lernstufe kann eine Anzahl von verschiedenen möglichen Formen annehmen. Zum Beispiel nehmen in einem überwachten Konzept die eingegebenen Erfahrungsdaten die Form von Trainingsdaten an, d.h., Eingaben, die bekannten Ausgaben entsprechen. Mit jedem Datenpunkt kann der Algorithmus die Parameter so anpassen, dass die Ausgabe enger zur bekannten Ausgabe für die gegebene Eingabe passt. In der anschließenden Vorhersagestufe kann die Grafik dann benutzt werden, um eine Eingabefrage auf eine ungefähr vorhergesagte Ausgabe abzubilden (oder umgekehrt, falls eine Schlussfolgerung gemacht wird). Andere Konzepte sind auch möglich. Zum Beispiel gibt es in einem nicht-überwachten Konzept kein Konzept eines Bezugsergebnisses je Eingabedaten, und stattdessen wird es dem Maschinenintelligenzalgorithmus überlassen, seine eigene Struktur in den Ausgangsdaten zu identifizieren. Oder in einem Verstärkungskonzept testet der Algorithmus wenigstens eine mögliche Ausgabe für jeden Datenpunkt in den eingegebenen Erfahrungsdaten und erfährt, ob diese Ausgabe positiv oder negativ ist (und potenziell ein Maß, wie positiv oder negativ) z.B. gewinnen oder verlieren oder Vergütung oder Kosten oder dergleichen. Über viele Versuche kann der Algorithmus allmählich die Parameter der Grafik anpassen, damit sie Eingaben vorhersagen können, die in einem positiven Ausgang resultieren. Die verschiedenen Konzepte und Algorithmen zum Lernen einer Grafik sind einem Fachmann im Gebiet des Maschinenlernens bekannt.
  • Gemäß einer beispielhaften Anwendung der hier offenbarten Techniken ist jeder Worker-Thread programmiert, um die Berechnungen durchzuführen, die zu einem jeweiligen einzelnen der Knoten 102 in einer Maschinenintelligenzgrafik wie beispielsweise einem neuronalen Netz gehören. In diesem Fall entsprechen wenigstens manche der Flanken 104 zwischen den Knoten 102 dem Datenaustausch zwischen Threads, und manche können einen Austausch zwischen Tiles einbeziehen. Im Fall einer Multitile-Anordnung 6 mit mehrfachen Threads je Tile 4, führt jeder Tile 4 eine Teilgrafik der Grafik aus. Jede Teilgrafik weist ein Supervisor-Subprogramm mit einem oder mehreren Supervisor-Threads und einen Satz von Worker-Threads, die die Knoten 102 der jeweiligen Teilgrafik darstellen, auf.
  • 7 zeigt eine beispielhafte Umsetzung eines vorteilhaften Wiederholungs-Cache-Mechanismus gemäß Ausführungsbeispielen der vorliegenden Offenbarung. Dieser kann Anwendung finden im Maschinenlernen, ist aber nicht auf solche Anwendungen beschränkt. Der Mechanismus beruht auf dem Bereitstellen eines Wiederholungsbefehls („rpt“) im Befehlssatz des Prozessors 4. Die Funktionalität des Wiederholungsbefehls ist so ausgestaltet, dass nicht nur a) ein erster Thread, der ihn ausführt, einen Teil seines eigenen Codes zwischenspeichert und diesen Teil des Codes wiederholt, sondern auch b) der nächste Thread zum Ausführen des Wiederholungsbefehls den vom ersten Thread zwischengespeicherten Teil des Codes wiederholen wird. So kann derselbe Code wiederverwendet und über mehrere Threads ohne erneutes Abrufen aus dem Speicher 12 dupliziert werden. In Ausführungsbeispielen wird derselbe Code in mehreren verschiedenen Threads jeweils zum Arbeiten gemäß ihren eigenen jeweiligen Operandenwerten in ihrer eigenen jeweiligen Registerdatei 26, z.B. ihrer eigenen jeweiligen ARF 26A wiederverwendet.
  • Die Erfinder haben ermittelt, dass in den Gebieten des Maschinenlernens und der neuronalen Netze Möglichkeiten entstehen, einen Code zwischen den Threads wiederzuverwenden, falls jeder Thread einen anderen jeweiligen Knoten in einer Grafik (z.B. einem neuronalen Netz) darstellt und manche der Knoten manche oder alle der gleichen Rechenprozesse durchführen. Zum Beispiel können die manche Knoten darstellenden Threads einen oder mehrere derselben Vorgänge auf ihren eigenen jeweiligen Eingangsdaten durchführen. Tatsächlich können in manchen Fällen die Threads mancher Knoten denselben Vorgang gemäß denselben Operandenwerten wie die anderen durchführen, aber gemäß manchen anderen Operanden, die für den einzelnen Thread spezifisch sind. Ein Beispiel wäre eine Vektor- oder Matrixmultiplikation, die als Teil einer Faltung durchgeführt wird, wodurch der Befehl in jedem Thread einen gemeinsamen Gewichtungssatz (von den Threads gemeinsam benutzt) mit Eingangsdaten multipliziert, die für den einzelnen Thread spezifisch sind. Dies kann in einem neuronalen Faltungsnetz stattfinden, in dem viele Knoten tatsächlich die gleichen Gewichtungen aber mit verschiedenen Verbindungen aufweisen. Jeder Thread kann ausgestaltet sein, um die Verarbeitung eines anderen jeweiligen Knotens im neuronalen Netz durchzuführen, wie beispielsweise eine Faltung eines gemeinsamen Kernels von Gewichtungen mit jeweiligen Eingangsdaten, um ein bestimmtes Merkmal zu erfassen.
  • In solchen Szenarien wäre es vorteilhaft, einen Mechanismus vorzusehen, der einen Teil des Codes von einem Thread in einem oder mehreren anderen Threads wiederverwenden lässt, ohne dass ihn jeder Thread separat aus dem Speicher wieder abrufen muss, womit ein Energieverbrauch in Szenarien reduziert wird, in denen Threads manche oder alle derselben Vorgänge durchführen. Z.B. kann dies in Szenarien eingesetzt werden, in denen dieselben Vorgänge durch jeden Thread gemäß einer Kombination eines oder mehrerer gemeinsamer Gewichtungsoperanden, die von den Threads gemeinsam benutzt werden, und eines oder mehrerer Operanden, die für den einzelnen jeweiligen Thread spezifisch sind, durchzuführen sind.
  • Der Vorteil des Wiederholungs-Cache in solchen Szenarien besteht darin, dass Befehlsabrufe aus dem Speicher 12 hinsichtlich der Energie aufwändig sind. Da zum Beispiel viele innere Schleifen in Anwendungen wie neuronalen Netzen (zum Beispiel für Faltung verwendete Schleifen) klein sind (eine Handvoll Befehle oder Bündel) und da Worker häufig jene gleichen Schleifen ausführen, gibt dies eine Möglichkeit zur Energieeinsparung durch Implementieren eines kleinen, lokalen und energieeffizienten Cache 31 im Tile 4. So können alle Worker anstelle des Durchführens aufwändiger Abrufe an den Speicher für denselben Code stattdessen den energieeffizienteren Cache benutzen.
  • Wie in 7 dargestellt, weist der Prozessor 4 gemäß der vorliegenden Offenbarung einen Befehls-Cache mit wenigstens einem Wiederholungs-Cache 31 auf. Der Wiederholungs-Cache 31 weist einen Zwischenspeicherbereich 33 zum vorübergehenden Halten mehrerer zwischengespeicherter Befehle der Reihe nach. Der Wiederholungs-Cache 31 hat auch eine zugeordnete Einrichtung 35 zum Protokollieren eines Status des Cache, wobei der Status wenigstens eine Protokollierung aufweist, ob der Cache aktuell durch einen der Threads „beansprucht“ (oder „besetzt“) wird oder nicht. Die Bedeutung hiervon wird in Kürze offensichtlich. Der Status 35 kann als ein interner Status des Wiederholungs-Cache 31 implementiert sein (d.h. Hardware-Schaltkreis in der Form eines oder mehrerer interner Latches). Alternativ könnte der Status 35 als ein Register in einer Registerdatei implementiert sein, z.B. als Steuerstatusregister 28 eines der Kontexte wie beispielsweise des Supervisor-Kontextes.
  • Die Befehlsabrufstufe 14 der Pipeline 13 ist funktionsfähig, um Befehle von entweder dem Befehlsspeicher 12 oder dem Wiederholungs-Cache 31 abzurufen. Welche Quelle von Befehlen zu irgendeiner bestimmten Zeit benutzt wird, hängt vom Wiederholungsbefehl und seinen Operanden ab, wie in Kürze in mehr Einzelheiten erläutert.
  • Wie in 7 veranschaulicht, ist jeder der J Worker-Threads, die gleichzeitig ausgeführt werden können, einem anderen jeweiligen von mehreren J Sätzen von Kontextregistern 26(CX0...CXJ-1) zugeordnet, wobei jeder Satz ausgebildet ist, um den Programmstatus seines jeweiligen Workers zu halten. In Ausführungsbeispielen ist ein zusätzlicher Satz von Kontextregistern 26(CXS) vorgesehen, um den Programmstatus des Supervisor-Threads zu halten. Jeder Satz von Kontextregistern weist einen jeweiligen Programmzähler (PC) 21 zum Halten des aktuellen PC-Werts des jeweiligen Threads auf. Der Programm-Pointer bestimmt den aktuellen Punkt im jeweiligen Code des Threads, von dem seine Befehle abzurufen sind. Jeder Satz von Kontextregistern weist auch Operandenregister 32 zum vorübergehenden Halten von Operanden, gemäß denen durch die Befehle des jeweiligen Threads zu arbeiten ist, auf. Die Operandenregister 32 jedes Worker-Threads können die MRF 26M und die ARF 26A des jeweiligen Threads aufweisen. Die Operandenregister 32 des Supervisors können die WRF 26W aufweisen. Jeder Satz von Kontextregistern kann ferner einen oder mehrere entsprechende Steuerstatusregister (CRSs) 28 zum Protokollieren eines Status des jeweiligen Threads, beispielsweise ob er aktuell pausiert, aufweisen.
  • Für jeden Thread beginnt die Pipeline 13 durch Abrufen und Ausführen von Befehlen aus dem Befehlsspeicher 12 gemäß ihrem jeweiligen Programmzähler (PC). In bevorzugten Ausführungsbeispielen nimmt der Wiederholungsbefehl (rpt) die folgende Syntax:
    • rpt $size, $count
  • D.h. er nimmt zwei Operanden: einen Wiederholungsgröße-Operanden, der eine Größe eines Teils des Wiederholungscodes bestimmt, und einen Wiederholungszahl-Operanden, der eine Häufigkeit bestimmt, mit der der Teil wiederholt werden soll. In Ausführungsbeispielen bestimmen diese Operanden ihre jeweiligen Werte unter Bezugnahme auf ein Register. D.h. der direkt im Operandenfeld des Befehls enthaltene Wert identifiziert ein Register $size oder $count z.B. in der MRF 26M des jeweiligen Threads, aus dem der Ist-Wert der Wiederholungsgröße bzw. der Wiederholungszahl zu nehmen ist. Alternativ können einer oder beide dieser Operanden jedoch auch direkte Operanden sein (d.h. die Wiederholungsgröße und/oder die Wiederholungszahl sind direkt in das relevante Operandenfeld des Wiederholungsbefehls codiert).
  • Im Betrieb sind die Ausführungseinheit 18 und die Abrufstufe 14 ausgestaltet, um als Reaktion auf den Wiederholungsbefehl wie folgt zu arbeiten. Der erste Thread zum Ausführen von rpt $size, $count wird den Wiederholungs-Cache 31 beanspruchen. Dies kann auch als Blockieren des Wiederholungs-Cache 31 oder „Besetzen“ des Wiederholungs-Cache beschrieben werden. In der Praxis bedeutet dies, dass die Ausführungseinheit 18 den Status 35 des Wiederholungs-Cache 31 setzt, um ihn als beansprucht zu markieren. Danach kann kein anschließender Worker zum Ausführen des Wiederholungsbefehls den Wiederholungs-Cache beanspruchen, bis der Status 35 zurückgesetzt wird (siehe unten).
  • Wenn ein Worker den rpt ausführt, informiert dieser Befehl die Befehlsabruferlogik 14, um für die Befehlsabrufe in den Wiederholungs-Cache zu schauen. Die Ausführung des Wiederholungsbefehls im ersten Worker wird die Ausführungseinheit 18 veranlassen, den Wiederholungs-Cache 31 mit den anschließenden N Befehlen oder Befehlsbündeln dieses Workers unmittelbar nach der Position des Wiederholungsbefehls im Code zu füllen, wobei N in $size bestimmt ist (außer $size ist größer als die Kapazität des Widerholungs-Cache, in welchem Fall nur der erste Teil des Wiederholungskörpers im Wiederholungs-Cache 31 gespeichert wird). Die Ausführungseinheit 18 führt jene Befehle auch ein erstes Mal aus, während sie zwischengespeichert werden. Anschließend wird die Abrufstufe 14 unmittelbar nach dem Ende des Teils der N Befehle dazu veranlasst, zurückzugehen und das Abrufen des Codes aus dem Speicherbereich 33 des Wiederholungs-Cache 31 zu starten, und der zwischengespeicherte Teil des Codes wird dann daraus mit einer Häufigkeit abgerufen, die in $count bestimmt ist. Dies kann ein Abzweigen des Programmzählers PC 21 des jeweiligen Threads einbeziehen. Nach dem Ende der letzten Wiederholung wird das Programm ab dem Punkt unmittelbar nach dem zwischengespeicherten Teil des Codes fortgesetzt.
  • Wenn eine andere Instanz des Widerholungsbefehls als Teil eines zweiten der Worker-Threads ausgeführt wir, während der Wiederholungs-Cache gemäß seinem Status 35 noch beansprucht (blockiert) ist, dann lässt die Ausführung des Wiederholungsbefehls die Ausführungseinheit 18 eine andere Funktionalität bezüglich des zweiten Threads ausführen. Das heißt die Abrufstufe 14 wird gesteuert, um ein Abrufen des zwischengespeicherten Teils des Codes aus dem Speicherbereich 33 des Wiederholungs-Cache 31 zu beginnen (den Teil des Codes, der vom ersten Thread zwischengespeichert wurde). Sie wird dann die Ausführung dieses Teils des zwischengespeicherten Codes wiederholen, mit einer durch den jeweiligen $count - Operanden des zweiten Worker-Threads bestimmten Häufigkeit.
  • So sieht der Wiederholungsbefehl eine Null-Overhead-Schleifeneinrichtung vor, was die anschließende Folge von Befehlen oder Befehlsbündeln (den Wiederholungskörper) wiederholt ausgeführt werden lässt. Die Wiederholungszahl kann als ein direkter oder als ein vorzeichenloser Registerquellenwert vorgesehen sein. Die Größe des Wiederholungskörpers wird in einer Gesamtzahl von Befehlen oder Befehlsbündeln ausgedrückt und durch einen direkten Wert vorgesehen (z.B. mit der Wiederholungskörpergröße als (direkt + 1)-Ausführung).
  • Man beachte: das Nachschlagen im Wiederholungs-Cache kann noch auf zwei Weisen fehlschlagen. Die erste ist, falls der zweite Worker eine andere Instanz des Wiederholungsbefehls (ansässig an einer anderen Position im Speicher) ausgeführt hat und daher der Körper der Wiederholungsschleife nicht im Cache 31 ist. In diesem Fall wird die Befehlsabruflogik 14 melden, aus dem Speicher 12 abzurufen. Die zweite Weise ist, falls die Länge des Wiederholungskörpers die Kapazität des Wiederholungs-Cache übersteigt, in welchem Fall man das Endstück des Wiederholungskörpers nicht im Wiederholungs-Cache finden wird und der Abruf an den Befehlsspeicher 12 noch durchgeführt werden muss.
  • Der Wiederholungs-Cache 31 sieht einen kleinen, (meist) architektonisch unsichtbaren Befehls-Cache vor, der auf ein Reduzieren des Code-Overheads und somit des Energieverbrauchs während z.B. inneren Schleifen eines Hochrechen-Kernels abzielt, insbesondere wenn eine Anzahl von Worker-Kontexten dieselbe Aufgabe durchführen. Der Cache 31 wird von den Worker-Kontexten gemeinsam benutzt und ist in Ausführungsbeispielen speziell nur für Cache-Befehle oder Bündel in den Wiederholungskörpern von Instanzen des Wiederholungsbefehls reserviert.
  • In Ausführungsbeispielen besteht der Speicherbereich 33 des Wiederholungs-Cache aus einer Anzahl von unabhängigen Reihen, jede mit der gleichen Größe wie ein Befehl (im Fall von individuellen Befehlsausgaben) oder ein Befehlsbündel (falls der Prozessor Bündel von zusammen ausgegebenen Befehlen ausführt). Jede Reihe kann entweder gültig oder ungültig sein. Alle Reihen sind anfänglich ungültig. Da in Ausführungsbeispielen die Ausführungsbündel in den Wiederholungskörpern des Wiederholungsbefehls sind, sollten diese Bündel vorzugsweise auch in dem Tile-Speicher angepasst sein (z.B. auf 8 Byte angepasst).
  • Der Wiederholungs-Cache 31 ist entweder blockiert/gesperrt oder freigeschaltet. Wenn er freigeschaltet ist (der anfängliche Zustand), wird der Wiederholungs-Cache als ein Nebeneffekt des Worker-Threads (der Sperrkontext), der eine Instanz des Wiederholungsbefehls ausführt, gesperrt. Falls der Wiederholungs-Cache 31 bereits blockiert ist, wenn ein Worker-Kontext einen Wiederholungsbefehl ausführt, wird diesbezüglich keine weitere Aktion unternommen.
  • Es gibt zwei Möglichkeiten zum Implementieren des Mechanismus zum Zurücksetzen des Status 35, sodass das Beanspruchen (Blockieren) des Wiederholungs-Cache wieder freigegeben werden kann.
  • Die erste besteht darin, dass, wenn der Worker-Thread, der den Wiederholungs-Cache besetzt, den allerletzten Befehl in der Wiederholungsschleife ausführt, der Wiederholungs-Cache 31 freigeschaltet wird und alle Reihen 33 als ungültig markiert werden. Jeder andere Worker-Kontext, der aktuell den Wiederholungs-Cache benutzt, wird nun den Code aus dem Speicher 12 anstatt aus dem Wiederholungs-Cache 31 abrufen. Dies erfordert eine Einrichtung zum Protokollieren, welcher der Worker-Threads (oder eher welcher Kontext oder welches Fenster) den Befehls-Cache 31 beanspruchte (d.h. welcher seine Blockade verursachte). Dies könnte als ein Status im internen Status des Cache 31 oder in einem Register in einer der Registerdateien 26 implementiert werden.
  • Die zweite, bevorzugte Alternative besteht darin, dass ein Merker 41 für jeden Kontext (jeden der gleichzeitigen Threads oder jedes der Fenster) gehalten wird. Z.B. kann dies in einem der Steuerstatusregister 28 des jeweiligen Kontextes implementiert werden. Wenn der Wiederholungs-Cache einmal blockiert ist, wird der Merker für jeden Worker-Thread, der den Wiederholungs-Cache benutzt (trifft), gesetzt. Jedes Mal, wenn ein Kontext den letzten Befehl in seiner Wiederholungsschleife ausführt, wird dann, falls der einzige Merker, der gesetzt ist, der durch diesen Thread besetzte ist (d.h. alle anderen Merker sind gelöscht), der Wiederholungs-Cache 31 freigeschaltet. In jedem Fall wird der durch diesen Thread besetzte Merker 41 gelöscht. D.h. wenn der letzte Kontext, der den Wiederholungs-Cache benutzt, seine Wiederholungsschleife beendet, wird der Wiederholungs-Cache 31 freigeschaltet.
  • Man beachte: wo gesagt wird, welcher Thread den Cache 31 beansprucht, bedeutet dies, welcher der gleichzeitigen Threads, d.h. die gleichzeitig einem der Zeitfenster un dem zugehörigen Satz von Kontextregistern 26 zugeteilt sind. Äquivalent kann man sagen, welcher der Kontexte 26 (CX0... CXJ-1) den Cache beansprucht oder welches der Fenster S0... SJ-1 den Cache beansprucht. „Kontext“ wird in der Technik manchmal auch als Kurzbezeichnung für den den Kontext haltenden Satz von Registern 26 (im Sinne des Programmstatus) oder das Fenster, in dem der jeweilige Thread ausgeführt wird, benutzt; oder tatsächlich die gesamte Anordnung von Thread, Fenster, Programmstatus und Kontextregister.
  • Das Blockieren des Wiederholungs-Cache 31 leitet einen Cache-Füllvorgang ein. D.h. während einer Blockade veranlasst eine Ausführung jedes anschließenden Ausführungsbefehls oder Bündels an der Spitze des Wiederholungskörpers des blockierenden Kontextes i) die Zuteilung einer einzigen Reihe zu dieser befehls- oder Bündeladresse, ii) das Schreiben der Befehls- oder Ausführungsbündeldaten in die zugeteilte Reihe und iii) das Setzen der Reihe als gültig. Falls die Größe des Wiederholungskörpers größer als die Kapazität des Wiederholungs-Cache ist, werden nur die Ausführungsbündel an der Spitze des Wiederholungskörpers zwischengespeichert.
  • Im blockierten Zustand wird der Wiederholungs-Cache freigeschaltet, wenn der Wert von $count (des blockierenden Kontextes) 0 wird (erster Rücksetzmechanismus) oder wenn der relevante Merker gelöscht wird (zweiter Rücksetzmechanismus). Für alle Worker-Kontexte wird der Befehlsabrufmechanismus, wenn $count nicht Null ist (d.h. der Worker einen Wiederholungskörper ausführt), die Anwesenheit einer gültigen Reihe, die der Befehls- oder Ausführungsbündeladresse zugeteilt ist, überprüfen und im Fall eines Treffers die Inhalte der Cache-Reihe verwenden anstelle einen Abruf aus einem Tile-Speicher durchzuführen.
  • In Ausführungsbeispielen wird der Wiederholungsbefehl, falls die Wiederholungszahl anfänglich Null ist, als eine Abzweigung über den Wiederholungskörper agieren. Ansonsten werden die anschließenden Wiederholungskörper-Ausführungsbündel $count Mal ausgeführt.
  • In Ausführungsbeispielen, die Bündel von gemeinsam ausgegebenen Befehlen ausführen, wird jeder gemeinsam mit dem Wiederholungsbefehl ausgegebene Befehl nur einmal ausgeführt und ist nicht Teil des Wiederholungskörpers.
  • In Ausführungsbeispielen kann es nicht gestattet sein, bestimmte Befehlstypen in einem Wiederholungskörper auszuführen. In diesem Fall wird in einem Versuch, einen solchen Befehl auszuführen, eine Ausnahmeregelung getroffen.
  • Selbstverständlich sind die obigen Ausführungsbeispiele nur beispielhaft beschrieben worden.
  • Zum Beispiel erfordert in alternativen Implementierungen die Syntax des Wiederholungsbefehls nicht unbedingt einen Wiederholungsgröße-Operanden. Stattdessen könnte die Größe des zwischengespeicherten Teils fest (impliziert) oder durch irgendein anderes Stück des Status, z.B. eine durch den Supervisor gesetzte Einstellung des Wiederholungs-Cache, bestimmt sein. Man beachte auch, dass die Größe des Wiederholungskörpers nicht mit der Größe des Wiederholungs-Cache übereinstimmen muss.
  • Oder in komplexeren Implementierungen müssen die zwischengespeicherten Befehle (Wiederholungskörper) nicht unbedingt ab dem Befehl oder Bündel direkt nach dem Wiederholungsbefehl starten. Z.B. könnte die Syntax des Wiederholungsbefehls die Bestimmung eines Start- und Endpunkts zulassen. Oder als ein anderes Beispiel könnte der Prozessor die letzten M Befehle in einer durchlaufenden Art und Weise kontinuierlich zwischenspeichern, und dann lässt der Wiederholungszahl-Operand die letzten N von ihnen hin zum Wiederholungsbefehl zwischengespeichert werden. D.h. der Wiederholungsbefehl könnte nach anstelle vor dem Körper der Schleife ausgeführt werden.
  • In weiteren alternativen oder zusätzlichen Varianten erfordert der Prozessor 4 nicht unbedingt einen dedizierten Hardware-Mechanismus 41 zum Zurücksetzen der Beanspruchung des Wiederholungs-Cache 31 (d.h. Freischalten des Wiederholungs-Cache). In alternativen Implementierungen könnte diese explizit durch Software in einem der Worker oder des Supervisors z.B. durch Ausführen eines Setz-Befehls zum Schreiben in ein mit dem Wiederholungs-Cache verbundenes Register wie beispielsweise 35 zurückgesetzt werden (falls dieses als ein beschreibbares Register in einer Registerdatei implementiert ist).
  • Ferner ist der Schutzumfang der vorliegenden Offenbarung die oben beschriebene Architektur, in der ein separater Kontext für den Supervisor-Thread vorgesehen ist oder in der der Supervisor-Thread in einem Fenster läuft und dann sein Fenster an einen Worker abtritt. Der Supervisor könnte stattdessen auch einen Universal-Kontext verwenden.
  • Oder in einer anderen Ausgestaltung kann der Supervisor zum Beispiel in seinem eigenen dedizierten Fenster laufen. Ferner ist die Implementierung nicht auf einen speziellen Thread, der auch eine Supervisor-rolle hat, beschränkt. Ferner ist der Schutzumfang der Offenbarung nicht auf den Prozessor 4 als ein Tile in einer Anordnung von Tiles beschränkt. In alternativen Ausführungsbeispielen kann der Prozessor 4 zum Beispiel ein autarker Prozessor oder ein Ein-Chip-Prozessor sein.
  • Die Implementierung ist nicht auf separate MRF und ARF beschränkt. Auch ist sie nicht auf die Verwendung einer separaten WRF beschränkt. Allgemein können die Register aus einem oder mehreren Registerdateien sein, die von verschiedenen Speicherzugriff- und arithmetischen Vorgängen gemeinsam benutzt werden oder getrennt sind.
  • Ferner ist der Schutzumfang der Offenbarung nicht auf Maschinenlernanwendungen beschränkt. Es gibt viele andere Anwendungen, bei denen es erwünscht sein kann, einen Code zwischen Threads wiederzuverwenden, um einen Code-Overhead zu reduzieren d so die Code-Dichte zu verbessern.
  • Weitere Varianten oder Nutzungsfälle der offenbarten Techniken sind dem Fachmann anhand der hier gegebenen Offenbarung offensichtlich. Der Schutzumfang der Offenbarung ist nicht auf die beschriebenen Ausführungsbeispiele beschränkt, sondern nur durch die beigefügten Ansprüche.

Claims (20)

  1. Prozessor, aufweisend: eine Ausführungseinheit, die ausgestaltet ist, um Instanzen von in einem Befehlssatz definierten Befehlstypen auszuführen, wobei die Ausführungseinheit eine Barrelthread-Ausführungseinheit ist, die ausgestaltet ist, um mehrere gleichzeitige Threads jeweils in einem anderen einer Wiederholungssequenz von verschachtelten Zeitfenstern auszuführen; und einen Wiederholungs-Cache mit einem zugehörigen Status, der protokolliert, ob der Wiederholungs-Cache aktuell von einem der Threads beansprucht wird oder nicht, wobei die im Befehlssatz definierten Befehlstypen einen Wiederholungsbefehl enthalten, der einen Wiederholungszahl-Operanden nimmt, wobei die Ausführungseinheit ausgestaltet ist, um a) einen Teil des Codes vom ersten Thread in den Wiederholungs-Cache zwischenzuspeichern, den Status in eine Protokollierung des Wiederholungs-Cache als beansprucht zu modifizieren und den Teil des Codes mit einer entsprechenden Häufigkeit auszuführen, wobei jede folgende Wiederholung aus dem Wiederholungs-Cache genommen wird, wenn der Wiederholungs-Cache gemäß dem Status aktuell nicht beansprucht wird und eine jeweilige Instanz des Wiederholungsbefehls in einem ersten der Threads ausgeführt wird, und b) den schon zwischengespeicherten Teil des Codes mit einer entsprechenden Häufigkeit jedes Mal aus dem Wiederholungs-Cache auszuführen, wenn der Wiederholungs-Cache gemäß dem Status aktuell beansprucht wird und eine weitere Instanz des Wiederholungsbefehls dann als Teil irgendeines weiteren der Threads ausgeführt wird bis der Status dann in eine Protokollierung des Wiederholungs-Cache als wieder nicht beansprucht zurückgesetzt wird; und wobei für jeden des ersten und der weiteren Befehle der Wiederholungszahl-Operand im jeweiligen Befehl die entsprechende Häufigkeit zum Ausführen des Teils des Codes bestimmt, wobei der Wiederholungszahl-Operand irgendeinen von mehreren positiven ganzzahligen Werten für die entsprechende Häufigkeit zum Ausführen des Teils des Codes bestimmen kann.
  2. Prozessor nach Anspruch 1, bei welchem der Teil des Codes ein Teil nach der Instanz des Wiederholungsbefehls im ersten Thread ist.
  3. Prozessor nach Anspruch 2, bei welchem der Wiederholungsbefehl einen Wiederholungsgröße-Operanden zum Bestimmen einer Größe des Teils des Codes nimmt und bei welchem der Teil des Codes von einem vordefinierten Punkt nach der Instanz des Wiederholungsbefehls im ersten Thread bis zu einem anschließenden Punkt, der durch den Größe-Operanden der jeweiligen Instanz des Wiederholungsbefehls im ersten Thread definiert ist, läuft.
  4. Prozessor nach einem der vorhergehenden Ansprüche, bei welchem der Wiederholungszahl-Operand außerdem einen Wert von Null nehmen kann und der Wiederholungsbefehl die Ausführungseinheit die Ausführung des Teils des Codes im jeweiligen Thread einschließlich im Fall des ersten Threads überspringen lässt, falls die Wiederholungszahl Null ist.
  5. Prozessor nach einem der vorhergehenden Ansprüche, bei welchem der Wiederholungsbefehl die Ausführungseinheit den Teil des Codes nur einmal ohne Wiederholung als Teil des jeweiligen Threads ausführen lässt, falls die Wiederholungszahl Eins ist.
  6. Prozessor nach einem der vorhergehenden Ansprüche, bei welchem der Wiederholungszahl-Operand ein direkter Operand ist und/oder der Wiederholungsgröße-Operand ein direkter Operand ist.
  7. Prozessor nach einem der vorhergehenden Ansprüche, bei welchem der Wiederholungszahl-Operand die jeweilige Häufigkeit zum Ausführen des Teils des Codes durch Bezugnahme auf ein Register, aus dem die jeweilige Zahl zu lesen ist, bestimmt, und/oder der Wiederholungsgröße-Operand die Größe durch Bezugnahme auf ein Register, aus dem die Größe zu lesen ist, bestimmt.
  8. Prozessor nach einem der vorhergehenden Ansprüche, aufweisend einen Hardware-Mechanismus zum automatischen Zurücksetzen des Status in eine Protokollierung des Wiederholungs-Cache als wieder nicht beansprucht, wenn wenigstens einer des ersten und der weiteren Threads die Ausführung des zwischengespeicherten Teils des Codes mit seiner entsprechenden Häufigkeit beendet hat.
  9. Prozessor nach Anspruch 8, bei welchem der Mechanismus ausgestaltet ist, um des Status automatisch zurückzusetzen, wenn der erste Thread die Ausführung des zwischengespeicherten Teils des Codes mit seiner entsprechenden Häufigkeit beendet hat.
  10. Prozessor nach Anspruch 8, bei welchem der Mechanismus ausgestaltet ist, um die Beanspruchung des Wiederholungs-Cache automatisch zu löschen, wenn alle ersten und weiteren Threads die Ausführung des zwischengespeicherten Teils des Codes mit ihren entsprechenden Häufigkeiten beendet haben.
  11. Prozessor nach einem der vorhergehenden Ansprüche, aufweisend mehrere Sätze von Kontextregistern, wobei jeder Satz ausgebildet ist, um einen Programmstatus eines der gleichzeitigen Threads zu halten, wobei die Ausführungseinheit ausgestaltet ist, um als Reaktion auf den Wiederholungsbefehl in jedem der ersten und weiteren Threads denselben Teil des Codes aber unter Bearbeitung gemäß einem oder mehreren jeweiligen Operandenwerten, die in einem oder mehreren des dem jeweiligen Thread eigenen jeweiligen Satz von Kontextregistern gehalten sind, auszuführen.
  12. Prozessor nach Anspruch 11, bei welchem die gleichzeitigen Threads mehrere Worker-Threads aufweisen und die Ausführungseinheit ferner ausgebildet ist, um wenigstens manchmal ein Supervisor-Subprogramm mit wenigstens einem Supervisor-Thread zum Managen der Worker-Threads auszuführen.
  13. Prozessor nach Anspruch 12, bei welchem die Kontextregister jeweils einen entsprechenden Satz von Kontextregistern für jeden der Worker-Threads, die gleichzeitig ausgeführt werden können, und einen zusätzlichen Satz von Kontextregistern zum Halten eines Programmstatus des Supervisor-Subprogramms aufweisen.
  14. Prozessor nach Anspruch 13, bei welchem das Supervisor-Subprogramm ausgebildet ist, um durch anfängliches Laufen in allen Fenstern zu beginnen und dann die Worker-Threads durch Abtreten von manchen oder allen Fenstern, in denen das Supervisor-Subprogramm anfänglich gelaufen ist, an die entsprechenden Worker-Threads zu starten.
  15. Prozessor nach Anspruch 14, bei welchem der Befehlssatz einen Laufbefehl enthält, der bei Ausführung als Teil des Supervisor-Subprogramms das Fenster, in dem der Laufbefehl ausgeführt wird, an einen der Worker-Threads abtreten lässt, sodass der Worker-Thread in diesem Fenster anstelle des Supervisor-Subprogramms gestartet wird.
  16. Prozessor nach Anspruch 15, bei welchem der Befehlssatz einen Ausstiegsbefehl enthält, der bei Ausführung als Teil eines der Worker-Threads das Fenster, in dem der Ausstiegsbefehl ausgeführt wird, an das Supervisor-Subprogramm zurückgeben lässt, sodass das Supervisor-Subprogramm in diesem Fenster anstelle des Worker-Threads weiterläuft.
  17. Prozessor nach einem der Ansprüche 11 bis 16, bei welchem wenigstens einer der Befehle in dem Teil des Codes von einem Typ ist, der gemäß einer Kombination aus i) wenigstens einem Operandenwert aus wenigstens einem Register in dem jeweiligen Satz von Kontextregistern und ii) wenigstens einem Operandenwert aus wenigstens einem Register in einem Satz von gemeinsamen Operandenregistern, die den Worker-Threads gemeinsam sind, arbeitet.
  18. Prozessor nach Anspruch 17 abhängig von einem der Ansprüche 12 bis 16, bei welchem der Satz von gemeinsam benutzten Registerdateien so ausgestaltet ist, dass nur das Supervisor-Subprogramm einen Wert in den Satz der gemeinsamen Register schreiben kann, während die Worker-Threads nur aus dem Satz der gemeinsamen Register lesen können.
  19. Computerprogramm auf einem computerlesbaren Speicher, aufweisend einen Code zur Ausführung auf dem Prozessor nach einem der vorhergehenden Ansprüche, wobei der Code die Threads aufweist, von denen wenigstens manche Instanzen des Wiederholungsbefehls enthalten, die so ausgestaltet sind, dass wenigstens einer der Threads den im Wiederholungs-Cache durch einen anderen der Threads zwischengespeicherten Teil des Codes wiederverwendet.
  20. Verfahren zum Betreiben eines Prozessors nach einem der Ansprüche 1 bis 18, wobei das Verfahren ein Ausführen eines Programms mit den Threads auf dem Prozessor durch die Ausführungseinheit aufweist, wobei wenigstens manche der Threads Instanzen des Wiederholungsbefehls enthalten, die so ausgestaltet sind, dass wenigstens einer der Threads den im Wiederholungs-Cache durch einen anderen der Threads zwischengespeicherten Teil des Codes wiederverwendet.
DE102019112301.1A 2018-12-27 2019-05-10 Befehls-Cache in einem Multithread-Prozessor Pending DE102019112301A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1821229.0A GB2580316B (en) 2018-12-27 2018-12-27 Instruction cache in a multi-threaded processor
GB1821229.0 2018-12-27

Publications (1)

Publication Number Publication Date
DE102019112301A1 true DE102019112301A1 (de) 2020-07-02

Family

ID=65364666

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019112301.1A Pending DE102019112301A1 (de) 2018-12-27 2019-05-10 Befehls-Cache in einem Multithread-Prozessor

Country Status (7)

Country Link
US (2) US11567768B2 (de)
JP (1) JP6918051B2 (de)
CN (1) CN111381883B (de)
CA (1) CA3040901C (de)
DE (1) DE102019112301A1 (de)
FR (1) FR3091362B1 (de)
GB (1) GB2580316B (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11314515B2 (en) 2019-12-23 2022-04-26 Intel Corporation Instructions and logic for vector multiply add with zero skipping
CN112379928B (zh) * 2020-11-11 2023-04-07 海光信息技术股份有限公司 指令调度方法以及包括指令调度单元的处理器
CN116090383A (zh) * 2022-12-27 2023-05-09 广东高云半导体科技股份有限公司 实现静态时序分析的方法、装置、计算机存储介质及终端

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5579493A (en) * 1993-12-13 1996-11-26 Hitachi, Ltd. System with loop buffer and repeat control circuit having stack for storing control information
US20020078333A1 (en) * 2000-12-20 2002-06-20 Intel Corporation And Analog Devices, Inc. Resource efficient hardware loops
US20080294882A1 (en) * 2005-12-05 2008-11-27 Interuniversitair Microelektronica Centrum Vzw (Imec) Distributed loop controller architecture for multi-threading in uni-threaded processors
US20180181400A1 (en) * 2016-12-27 2018-06-28 Intel Corporation Apparatus and methods to support counted loop exits in a multi-strand loop processor

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS60241136A (ja) 1984-05-16 1985-11-30 Mitsubishi Electric Corp デ−タ処理装置
JPH06243036A (ja) * 1993-02-12 1994-09-02 Hitachi Ltd キャッシュ制御システム
JP2926045B2 (ja) 1997-06-18 1999-07-28 松下電器産業株式会社 マイクロプロセッサ
US6567895B2 (en) * 2000-05-31 2003-05-20 Texas Instruments Incorporated Loop cache memory and cache controller for pipelined microprocessors
US7178013B1 (en) * 2000-06-30 2007-02-13 Cisco Technology, Inc. Repeat function for processing of repetitive instruction streams
JP3796124B2 (ja) 2001-03-07 2006-07-12 株式会社ルネサステクノロジ スレッド間優先度可変プロセッサ
US7600076B2 (en) * 2006-03-16 2009-10-06 International Business Machines Corporation Method, system, apparatus, and article of manufacture for performing cacheline polling utilizing store with reserve and load when reservation lost instructions
US7987347B2 (en) 2006-12-22 2011-07-26 Broadcom Corporation System and method for implementing a zero overhead loop
EP2453350B1 (de) 2007-06-20 2016-04-27 Fujitsu Limited Verarbeitungsvorrichtung
US8868888B2 (en) * 2007-09-06 2014-10-21 Qualcomm Incorporated System and method of executing instructions in a multi-stage data processing pipeline
US20120079303A1 (en) 2010-09-24 2012-03-29 Madduri Venkateswara R Method and apparatus for reducing power consumption in a processor by powering down an instruction fetch unit
JP2011070695A (ja) 2010-12-03 2011-04-07 Hitachi Ltd プロセッサ
US8639882B2 (en) * 2011-12-14 2014-01-28 Nvidia Corporation Methods and apparatus for source operand collector caching
US9558000B2 (en) * 2014-02-06 2017-01-31 Optimum Semiconductor Technologies, Inc. Multithreading using an ordered list of hardware contexts
WO2016103092A1 (en) * 2014-12-22 2016-06-30 Centipede Semi Ltd. Run-time code parallelization with continuous monitoring of repetitive instruction sequences
US11294815B2 (en) * 2015-06-10 2022-04-05 Mobileye Vision Technologies Ltd. Multiple multithreaded processors with shared data cache
JP2017228213A (ja) 2016-06-24 2017-12-28 富士通株式会社 演算処理装置及び演算処理装置の制御方法
US10776310B2 (en) 2017-03-14 2020-09-15 Azurengine Technologies Zhuhai Inc. Reconfigurable parallel processor with a plurality of chained memory ports
GB201717303D0 (en) 2017-10-20 2017-12-06 Graphcore Ltd Scheduling tasks in a multi-threaded processor

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5579493A (en) * 1993-12-13 1996-11-26 Hitachi, Ltd. System with loop buffer and repeat control circuit having stack for storing control information
US20020078333A1 (en) * 2000-12-20 2002-06-20 Intel Corporation And Analog Devices, Inc. Resource efficient hardware loops
US20080294882A1 (en) * 2005-12-05 2008-11-27 Interuniversitair Microelektronica Centrum Vzw (Imec) Distributed loop controller architecture for multi-threading in uni-threaded processors
US20180181400A1 (en) * 2016-12-27 2018-06-28 Intel Corporation Apparatus and methods to support counted loop exits in a multi-strand loop processor

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
Barrel processor. In: Wikipedia, the free encyclopedia. Bearbeitungsstand: 26.11.2018. URL: https://en.wikipedia.org/w/index.php?title=Barrel_processor&oldid=870708296 [abgerufen am 06.03.2020] *
Ratković, Ivan [et al.]: Chapter One – An Overview of Architecture-Level Power- and Energy-Efficient Design Techniques. In: Advances in Computers, 98, 2015, S. 1, 2, 12, 34, 35. - ISSN 0065-2458. http://hdl.handle.net/2117/88607 [abgerufen am 09.03.2020] *
Simultaneous multithreading. In: Wikipedia, the free encyclopedia. Bearbeitungsstand: 17.12.2018. URL: https://en.wikipedia.org/w/index.php?title=Simultaneous_multithreading&oldid=874139330 [abgerufen am 06.03.2020] *
Thread (computing). In: Wikipedia, the free encyclopedia. Bearbeitungsstand: 03.12.2018. URL: https://en.wikipedia.org/w/index.php?title=Thread_(computing)&oldid=871757983 [abgerufen am 06.03.2020] *
Thread pool. In: Wikipedia, the free encyclopedia. Bearbeitungsstand: 19.11.2018. URL: https://en.wikipedia.org/w/index.php?title=Thread_pool&oldid=869616238 [abgerufen am 06.03.2020] *

Also Published As

Publication number Publication date
CA3040901C (en) 2021-05-04
GB2580316B (en) 2021-02-24
GB201821229D0 (en) 2019-02-13
FR3091362B1 (fr) 2023-04-21
CA3040901A1 (en) 2020-06-27
US20200210192A1 (en) 2020-07-02
JP6918051B2 (ja) 2021-08-11
CN111381883A (zh) 2020-07-07
US20220197645A1 (en) 2022-06-23
GB2580316A (en) 2020-07-22
FR3091362A1 (fr) 2020-07-03
JP2020107306A (ja) 2020-07-09
CN111381883B (zh) 2023-09-29
US11567768B2 (en) 2023-01-31

Similar Documents

Publication Publication Date Title
DE102019112353A1 (de) Lade/speicher-befehl
DE69133302T2 (de) Registerabbildung in einem einzigen Taktzyklus
DE102018126001A1 (de) Synchronisation in einem Multi-Kachel-Verarbeitungsarray
DE102019112352A1 (de) Registerdateien in einem multithread-prozessor
DE69636861T2 (de) Mikroprozessor mit Lade-/Speicheroperation zu/von mehreren Registern
DE4211245B4 (de) Prozessorsystem in Parallelverarbeitungsbauart und Verfahren zu dessen Steuerung
DE102019112301A1 (de) Befehls-Cache in einem Multithread-Prozessor
DE112015004983T5 (de) Parallel-Slice-Prozessor mit einer Lade-Speicher-Umlaufwarteschlange für eine schnelle Freigabe von Einträgen in einer Ausgabewarteschlange
DE102015112202A1 (de) Kombinieren von Pfaden
DE112015005597T5 (de) Verknüpfungsfähige Parallelausführungs-Schicht einer Ausgabewarteschlange für einen Prozessor
DE102018126003A1 (de) Kombinieren von Zuständen mehrerer Threads in einem Multithread-Prozessor
DE112017003340T5 (de) Unterbrechungsfähige und neustartfähige matrix-multiplikationsinstruktionen, prozessoren, verfahren, und systeme
DE202017101012U1 (de) Compilerverwalteter Speicher für Bildprozessor
DE19855806A1 (de) Vorrichtung und Verfahren zum Durchführen von Unterprogrammaufruf- und Rücksprungoperationen
DE112013004770T5 (de) Lese- und -Schreibmaskenaktualisierungsbefehl zur Vektorisierung rekursiver Berechnungen über unabhängige Daten
DE102009038454A1 (de) System und Verfahren zum Reduzieren einer Ausführungsdivergenz in Parallelverarbeitungsarchitekturen
DE102005021749A1 (de) Verfahren und Vorrichtung zur programmgesteuerten Informationsverarbeitung
DE102012210895A1 (de) Vorhersage der ungeordneten Parallelverarbeitung der Befehle von Threads in einem Multithread-Prozessor
DE112013006309T5 (de) Funktionseinheit mit Baumstruktur zur Unterstützung eines Vektorsortieralgorithmus und anderer Algorithmen
DE19545179A1 (de) Vektorspeicheroperationen
DE112019000676T5 (de) Zentraler scheduler und anweisungszuteiler für einen neuronalen inferenzprozessor
DE112017001700T5 (de) Prozessoren, Verfahren, Systeme und Anweisungen zum Abruf von Daten auf der angegebenen Cache-Ebene mit garantiertem Abschluss
EP0825540A1 (de) Prozessor mit Pipelining-Aufbau
DE102015015182A1 (de) Systeme, Vorrichtungen und Verfahren zur k-Nächste-Nachbarn-Suche
DE112017000968T5 (de) System und Verfahren zur kontextabhängigen Vektorisierung von Befehlen zur Laufzeit

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication