DE102009004810A1 - Verfahren zum Ausführen eines oder mehrerer Programme auf einem Mehrkernprozessor und Mehrkernprozessor - Google Patents

Verfahren zum Ausführen eines oder mehrerer Programme auf einem Mehrkernprozessor und Mehrkernprozessor Download PDF

Info

Publication number
DE102009004810A1
DE102009004810A1 DE102009004810A DE102009004810A DE102009004810A1 DE 102009004810 A1 DE102009004810 A1 DE 102009004810A1 DE 102009004810 A DE102009004810 A DE 102009004810A DE 102009004810 A DE102009004810 A DE 102009004810A DE 102009004810 A1 DE102009004810 A1 DE 102009004810A1
Authority
DE
Germany
Prior art keywords
execution
program
unit
execution unit
local memory
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.)
Ceased
Application number
DE102009004810A
Other languages
English (en)
Inventor
Sascha Uhrig
Wolfgang Trumler
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.)
Universitaet Augsburg
Original Assignee
Universitaet Augsburg
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 Universitaet Augsburg filed Critical Universitaet Augsburg
Priority to DE102009004810A priority Critical patent/DE102009004810A1/de
Priority to US12/685,416 priority patent/US20100180101A1/en
Publication of DE102009004810A1 publication Critical patent/DE102009004810A1/de
Ceased legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5033Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering data affinity
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multi Processors (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Ausführen eines Programmteile umfassenden Programms auf einem Mehrkernprozessor (1) mit einer Mehrzahl an Ausführungseinheiten (21, 22, 23, 24), welche jeweils einen lokalen Speicher (201) und zumindest eine kommunikativ mit dem lokalen Speicher verbundene Recheneinheit (202) umfassen, wobei jede der Ausführungseinheiten (21, 22, 23, 24) zum Datenaustausch mit einem Kommunikationsnetzwerk (30) verbunden ist. Es werden ein oder mehrere Programmteile des Programms in zumindest manche der lokalen Speicher (201) der Mehrzahl an Ausführungseinheiten (21, 22, 23, 24) eingespeichert. Die Ausführung eines jeweiligen Programmteils des Programms erfolgt durch die Recheneinheit (202) derjenigen Ausführungseinheit (21, 22, 23, 24), welche in ihrem lokalen Speicher (201) das Programmteil gespeichert hat.

Description

  • Die Erfindung betrifft ein Verfahren zum Ausführen eines Programmteile umfassenden Programms auf einem Mehrkernprozessor, der eine Mehrzahl an Ausführungseinheiten umfasst, die zum Datenaustausch mit einem Kommunikationsnetzwerk verbunden sind. Die Erfindung betrifft ferner ein Computerprogramm sowie einen Mehrkernprozessor der oben bezeichneten Art.
  • Die Programmabarbeitung von Prozessoren ist dadurch gekennzeichnet, dass für die Ausführung eines Programms sowohl dessen Code als auch dafür notwendige Daten für den Prozessor verfügbar, d. h. beim Prozessor vorhanden, sein müssen. Stehen dem Prozessor entweder der Code oder notwendige Daten nicht zur Verfügung, so müssen diese mit entsprechendem zeitlichem Aufwand aus einem Speicher, der kommunikativ mit dem Prozessor verbunden ist, geladen werden. Problematisch ist hierbei, dass die Kommunikationsverbindung zwischen dem Speicher und dem Prozessor verhältnismäßig langsam ist.
  • Bei Mehrkernprozessoren (sog. Multi-Core-Prozessoren) mit mehreren als Prozessorkerne bezeichneten Ausführungseinheiten kann dies dazu führen, dass durch den zeitaufwändigen Transport nachzuladender Daten oder nachzuladendem Code die Rechenleistung im Vergleich zu einem Prozessor mit lediglich einer einzigen Ausführungseinheit (sog. Single-Core-Prozessor) abfällt. Darüber hinaus ist bei einem Mehrkernprozessor das Auftreten von Redundanzen möglich. Dies bedeutet, ein und dasselbe Datum ist zeitgleich (und damit redundant) in lokalen Speichern mehrerer Ausführungseinheiten gespeichert. Die lokalen Speicher werden typischerweise als Cache-Speicher bezeichnet. Hierdurch ergibt sich die Notwendigkeit der Durchführung eines Konsistenzverfahrens, das die Daten in den Speichern aller Ausführungseinheiten konsistent hält. Diese Verfahren sind jedoch sehr aufwändig und erzeugen eine hohe Datenlast auf dem die Ausführungseinheiten miteinander verbindenden Kommunikationsnetzwerk. Bereits bei vier Ausführungseinheiten (Prozessorkernen) können hierdurch 50% der Gesamtlast verursacht sein. Bei Mehrkernprozessoren mit mehr als acht oder 16 Ausführungseinheiten (sog. Many-Core-Prozessoren) wird ein weiterer Anstieg des Anteils dieser Konsistenznachrichten erwartet.
  • Die durch Mehrkernprozessoren theoretisch zur Verfügung gestellte Rechenleistung lässt sich damit nicht in zufriedenstellender Weise ausnutzen. Es ist daher Aufgabe der vorliegenden Erfindung, ein verbessertes Verfahren zum Ausführen eines Programmteile umfassenden Programms auf einem Mehrkernprozessor anzugeben, welches die Steigerung der Performanz des Mehrkernprozessors ermöglicht. Es ist ferner Aufgabe der vorliegenden Erfindung, ein Computerprogramm anzugeben, mit welchem sich die Performanz eines Mehrkernprozessors steigern lässt. Eine weitere Aufgabe der Erfindung besteht darin, einen Mehrkernprozessor anzugeben, welcher im Vergleich zu den Mehrkernprozessoren aus dem Stand der Technik eine verbesserte Performanz erlaubt.
  • Diese Aufgaben werden durch ein Verfahren mit den Merkmalen des Patentanspruches 1, ein Computerprogramm mit den Merkmalen des Patentanspruches 17 sowie einen Mehrkernprozessor mit den Merkmalen des Patentanspruches 18 gelöst. Vorteilhafte Ausgestaltungen ergeben sich jeweils aus den abhängigen Patentansprüchen.
  • Die Erfindung schafft ein Verfahren zum Ausführen eines Programmteile umfassenden Programms auf einem Mehrkernprozessor mit einer Mehrzahl an Ausführungseinheiten. Als Ausführungseinheit wird in der vorliegenden Beschreibung ein Prozessorkern innerhalb eines Mehrkernprozessors (Multi- oder Many-Core-Prozessor) bezeichnet. Jede der Ausführungseinheiten umfasst einen lokalen Speicher und zumindest eine kommunikativ mit dem lokalen Speicher verbundene Recheneinheit. Dabei ist jede der Ausführungseinheiten zum Datenaustausch mit einem Kommunikationsnetzwerk verbunden. Das Kommunikationsnetzwerk kann als Bussystem oder sog. Network on a Chip (NoC) ausgebildet sein. Erfindungsgemäß werden ein oder mehrere Programmteile des Programms in zumindest manche der lokalen Speicher der Mehrzahl an Ausführungseinheiten eingespeichert. Ferner erfolgt die Ausführung eines jeweiligen Programmteils des Programms durch die Recheneinheit derjenigen Ausführungseinheit, welche in ihrem lokalen Speicher das Programmteil gespeichert hat.
  • Das der Erfindung zu Grunde liegende Prinzip besteht somit darin, anstatt Programmteile, welche jeweils Code und Daten umfassen, zu einer Ausführungseinheit zu transportieren, die Ausführung an den Ort, d. h. diejenige Ausführungseinheit, zu verlegen, an dem das oder die Programmteile bereits vorhanden sind. Durch die Vermeidung des Code- und Datentransports zum Ort der Ausführung wird nicht nur die Latenz bei der Ausführung eines Programms verringert, sondern es wird auch das Kommunikationsnetzwerk deutlich entlastet. Durch einen weitgehenden Verzicht auf den Transport von Daten und/oder Codes eines oder mehrerer Programmteile, kann die Ausführung des Programms verzögerungsfrei durch die Ausführungseinheit fortgesetzt werden, welche die entsprechenden Daten in ihrem lokalen Speicher hält.
  • In einer Ausgestaltung liest eine Ausführungskontexteinheit einer der Ausführungseinheiten zumindest einen Teil eines Ausführungskontextes des auf dieser Ausfüh rungseinheit ausgeführten Programmteils aus und überträgt diesen an eine andere der Ausführungseinheiten zur Ausführung, wenn zur weiteren Ausführung des ausgeführten Programmteils der auf der anderen Ausführungseinheit gespeicherte Programmteil benötigt wird. Der Ausführungskontext kann beispielsweise einen Registersatz einschließlich eines Befehlszählers und einen oder mehrere Funktionsparameter umfassen. Die Ausführungskontexteinheit, die Bestandteil der Recheneinheit einer Ausführungseinheit sein kann, kann wahlweise den gesamten Ausführungskontext oder nur Teile davon, z. B. lediglich Funktionsparameter, an die andere Ausführungseinheit übertragen. Die empfangende Ausführungseinheit, d. h. deren Ausführungskontexteinheit, überträgt die empfangenen Daten zur dort vorhandenen Recheneinheit, so dass anschließend die Ausführung des entsprechenden Programmteils des Programms erfolgen kann.
  • Es kann insbesondere vorgesehen sein, dass das Programm aus einer objektorientierten Programmiersprache erzeugt wird, wobei Objekte und zu einer Klasse der Objekte gehörender Programmcode des Programms auf zumindest manchen der Ausführungseinheiten in deren lokalen Speicher abgelegt werden. Programme objektorientierter Sprachen, wie beispielsweise C++, C#, Java oder Objective-C werden durch einen Compiler direkt in ausführbaren Maschinencode oder in Bytecode übersetzt. Durch die Kompilierung der Programme wird aus dem objektorientierten Programm Programmcode erzeugt, der die ausführbare Struktur des Programms enthält. Ein Objekt sowie zu einer Klasse der Objekte gehörender Programmcode stellen einen Programmteil des Gesamtprogramms dar, der auf dem Mehrkernprozessor läuft. Das erfindungsgemäße Verfahren lässt sich besonders gut zusammen mit der objektorientierten Programmierung anwenden, da bei einem Objekt Daten und Code in einer engen Beziehung stehen und entsprechend in einer Einheit gekapselt werden können. Objekte können in den lokalen Speichern der Ausführungseinheiten des Mehrkernprozessors abgelegt werden. Die Ausführung springt dann bei einem Methoden- oder Funktionsaufruf zu der Ausführungseinheit, die das Objekt (den Code und die Daten) im betreffenden lokalen Speicher hält.
  • Unabhängig davon ist das erfindungsgemäße Verfahren mit jeder Programmiersprache einsetzbar und nicht auf objektorientierte Programmiersprachen beschränkt.
  • Gemäß einer weiteren Ausgestaltung werden die Programmteile zur Laufzeit des Programms in einen jeweiligen lokalen Speicher der Mehrzahl an Ausführungseinheiten eingespeichert. Die Programmteile des Programms können damit zu Beginn und/oder während der Programmausführung in die jeweiligen lokalen Speicher eingespeichert werden.
  • Gemäß einer weiteren Ausgestaltung wird ein in den lokalen Speicher einer ersten Ausführungseinheit einzuspeichernder Programmteil in den lokalen Speicher einer zweiten, vorzugsweise räumlich benachbarten, Ausführungseinheit eingespeichert, wenn der lokale Speicher der ersten Ausführungseinheit erschöpft ist. Räumlich benachbart bedeutet in diesem Zusammenhang, dass die Kommunikationswege in dem Kommunikationsnetzwerk zwischen erster und zweiter Ausführungseinheit kurz gestaltet sind. Kurz ist in diesem Zusammenhang als zeitlich kurz zu verstehen. Insbesondere kann hierbei vorgesehen sein, dass in dem lokalen Speicher der ersten Ausführungseinheit optional ein Verweis auf den Programmteil in der zweiten Ausführungseinheit vorgesehen wird. Hierdurch können kurze Latenzen bei der Ausführung des Programms erzielt werden.
  • Im Falle einer objektorientierten Programmiersprache hat dies zur Folge, dass bei der Ausführung eines Methodenaufrufs auf einem entfernten Objekt die Ausführung durch Übermittlung einer Nachricht zu der entsprechenden, zweiten Ausführungseinheit wechselt und die Programmabarbeitung auf der entfernten zweiten Ausführungseinheit fortgesetzt wird. In der Nachricht müssen dann lediglich die Referenz auf das Objekt, die Methode sowie die notwendigen Parameter übermittelt werden. Auf der zweiten Ausführungseinheit ist zweckmäßigerweise auch der zu der Klasse des Objekts gehörende Programmcode abgelegt, um die schnelle Ausführung aller dieses Objekt betreffenden Funktionen zu gewährleisten. Weitere Objekte derselben Klasse können bevorzugt auf der zweiten Ausführungseinheit erzeugt werden.
  • Gemäß einer weiteren zweckmäßigen Ausgestaltung werden zeitlich ältere Programmteile in einen insbesondere außerhalb des Mehrkernprozessors vorgesehenen Speicher, insbesondere einen Cache-Speicher, ausgelagert, wenn die lokalen Speicher der Ausführungseinheiten ein Einspeichern neuer Programme nicht mehr erlauben. Dieses Vorgehen ist Bestandteil einer Auslagerungsstrategie, da in nur wenigen Fällen mehrere Programme vollständig in die lokalen Speicher der Ausführungseinheiten passen werden. Eine Auslagerung von Programmteilen kann grundsätzlich so lange vermieden werden, bis die lokalen Speicher aller Ausführungseinheiten des Mehrkernprozessors gefüllt sind. Erst dann muss für die Erzeugung eines neuen Programmteils bei einer Ausführungseinheit ein Teil des lokalen Speichers ausgelagert werden. Dieses Vorgehen entspricht somit einer herkömmlichen Auslagerungsstrategie in einen externen Speicher. Wird in Zukunft auf diese Programmteile wieder zugegriffen, so müssen diese in den lokalen Speicher einer der Ausführungseinheiten des Mehrkernprozessors geladen werden.
  • Im Rahmen dieses Speichermanagements kann weiterhin überprüft werden, ob ein Programmteil von dem lokalen Speicher einer ersten Ausführungseinheit in den lokalen Speicher einer zweiten Ausführungseinheit verschoben werden kann, bevor das Programmteil in den außerhalb des Mehrkernprozessors vorgesehenen Speicher verschoben wird. Das Auslagern von Programmteilen (insbesondere in herkömmlichen Prozessoren) ist ein zeitaufwändiger Vorgang, da immer mit einem externen Speicher oder einem Cache-Speicher kommuniziert werden muss. Der Zugriff auf die deutlich langsameren externen Speicher oder Cache-Speicher erhöht die Latenzen bis zur Ausführung des nächsten Befehls und verringert dadurch die Ausführungsgeschwindigkeit des Programms erheblich. Das Verschieben einzelner Programmteile auf andere Ausführungseinheiten umgeht dieses Problem, so dass die Ausführungsgeschwindigkeit des Programms hoch bleibt. Das Verschieben (oder auch interne Umlagern) kann dabei nur dann erfolgen, wenn freier lokaler Speicher auf einer der Ausführungseinheiten vorhanden ist. Auf dieser zweiten Ausführungseinheit steht der verschobene Programmteil dann sofort wieder zur Verfügung.
  • Gemäß einer weiteren Ausgestaltung wird ein Programmteil von dem lokalen Speicher einer ersten Ausführungseinheit in den lokalen Speicher einer zweiten, das Programm ausführenden oder in den lokalen Speicher einer dritten Ausführungseinheit verschoben, welche räumlich nahe zu der zweiten Ausführungseinheit gelegen ist. Hierdurch kann die Ausführung des Programms lokal auf wenigen Ausführungseinheiten gehalten werden, welche insbesondere räumlich benachbart zueinander angeordnet sind.
  • Das erfindungsgemäße Verfahren ermöglicht die beschleunigte Verarbeitung mehrerer paralleler Programm- oder Ausführungsstränge (sog. Threads oder Prozesse), da immer an einer der Verarbeitungseinheiten mit den bereits lokal vorhandenen Informationen (Code und Daten des Programmteils) ohne Verzögerung weitergearbeitet werden kann. Die Erzeugung eines neuen Ausführungsstrangs erfolgt auf der zur Laufzeit genutzten Ausführungseinheit oder einer davon verschiedenen Ausführungseinheit. Durch die Erzeugung und Nutzung von Programmteilen auf anderen Ausführungseinheiten springt die Ausführung dieses Ausführungsstrangs automatisch auf die andere(n) Ausführungseinheit(en). Somit werden die Ausführungsstränge aufgrund der verteilten Erzeugung der Programmteile automatisch in dem Mehrkernprozessor verteilt.
  • Um bereits bei der Erzeugung neuer Ausführungsstränge einen hohen Grad an Parallelität zu erhalten, kann ein neuer Ausführungsstrang von vorne herein auf einer anderen Ausführungseinheit erstellt werden. Bei einer großen Anzahl von Ausführungssträngen kann dadurch eine bessere Auslastung der vorhandenen Ausführungseinheiten erreicht werden. Eine hohe Lokalität der Programmteile (d. h. eine Verteilung der Programmteile auf räumlich nahe zueinander angeordneten Ausführungseinheiten) führt zu kurzen Kommunikationswegen und verringert die Latenzen bei der Programmausführung. Eine möglichst gute Verteilung der Ausführungsstränge erhöht den Grad der Parallelität.
  • Eine weitere Ausgestaltung sieht vor, dass bei der Ausführung mehrerer Ausführungsstränge auf einer Ausführungseinheit ein erstes Prozess-Steuerprogramm, insbesondere in der Ausführungskontexteinheit dieser Ausführungseinheit, vorgesehen ist, um die vorhandene Zeit der Recheneinheit zwischen den Ausführungssträngen aufzuteilen. Hierdurch ist vorteilhafter Weise keine Vorrichtung zur Synchronisation der Ausführungsstränge notwendig, da jeder Programmteil in dem Mehrkernprozessor nur einmal vorhanden ist. Der Zugriff kann über entsprechende Ausführungseinheiten erfolgen. Das Prozess-Steuerprogramm ist auch als Scheduling bekannt. Es können insbesondere herkömmliche Scheduling-Verfahren benutzt werden, um die vorhandene Prozessorzeit der Ausführungseinheit zwischen den Ausführungssträngen aufzuteilen.
  • Gemäß einer weiteren Ausgestaltung ist in einer jeweiligen Ausführungseinheit, insbesondere in der Ausführungskontexteinheit der Ausführungseinheit, ein zweites Prozess-Steuerprogramm (Scheduler) vorgesehen zur Verwaltung einer Mehrzahl an Ausführungsanfragen für ein und denselben Programmteil in der betreffenden Ausführungseinheit. Das zweite Prozess-Steuerprogramm kann beim Auftreten mehrerer Ausführungsanfragen die dringendste auswählen und diese zuerst ausführen.
  • Ferner kann gemäß einer weiteren Ausgestaltung in einer jeweiligen Ausführungseinheit, insbesondere in der Ausführungskontexteinheit der Ausführungseinheit, eine Look-Up-Tabelle vorgesehen sein. Diese erleichtert das Auffinden des Ziels der Übertragung, d. h. derjenigen Ausführungseinheit, welche den gesuchten Programmteil enthält.
  • Gemäß einer weiteren zweckmäßigen Ausgestaltung wird in einem außerhalb des Mehrkernprozessors vorgesehenen und mit dem Mehrkernprozessor in Kommunikationsverbindung stehenden Hauptspeicher eine globale Indirektionstabelle vorgesehen, welche virtuelle Adressen der Programmteile auf die physikalischen Adressen jeweiliger lokaler Speicher der Ausführungseinheiten abbildet. Dieser Ausgestaltung liegt die Erkenntnis zu Grunde, dass die Programmteile eines Programms auf den Ausführungseinheiten verteilt sind. Durch die Verteilung der Programmteile ist aber zunächst nur für den Erzeuger eines Programmteils die aktuelle Position dieses Teils bekannt. Möchte ein anderer Ausführungsstrang auf denselben Programmteil zugreifen, so muss dieser die Adresse des Programmteils, bestehend aus der Kennung der Ausführungseinheit und der lokalen Speicheradresse des Programmteils, ermitteln. Hierzu kann die globale Indirektionstabelle in dem Hauptspeicher verwendet werden. Wird ein Programmteil anhand seiner Speicheradresse gesucht, so kann dies durch einen Zugriff auf die Indirektionstabelle beantwortet werden. Der Vorteil besteht darin, dass die Referenzen der Programmteile, die durch Auslagerung oder einen Optimierungsalgorithmus von einer Ausführungseinheit zu einer anderen verlegt wurden, an einer zentralen Stelle, dem Hauptspeicher, aktualisiert werden können. Hierdurch wird der Aufwand vermieden, alle Ausführungseinheiten, die eine Referenz auf einen Programmteil besitzen, informieren zu müssen, wenn ein Programmteil verlegt wird.
  • Zweckmäßigerweise wird ein Teil der in die Indirektionstabelle zu speichernden Informationen in den jeweiligen lokalen Speichern der Ausführungseinheiten vorgehalten. Hierdurch ist vorteilhafterweise ein hierarchisches Verfahren realisiert. Die in den lokalen Speichern vorgehaltenen Informationen enthalten beispielsweise die am häufigsten erfragten Programmteiladressen. Wird ein Eintrag in der Ausführungseinheit-eigenen Teil-Indirektionstabelle nicht gefunden, so wird der Eintrag in der globalen Indirektionstabelle in dem Hauptspeicher ermittelt.
  • Gemäß einer weiteren zweckmäßigen Ausgestaltung wird zur Lokalisierung eines Programmteils ein Pointer-Routing-Verfahren eingesetzt, bei dem eine Ausführungsanfrage betreffend eines gesuchten Programmteils von einer Ausführungseinheit an eine andere Ausführungseinheit weitergeleitet wird, wenn der gesuchte Programmteil nicht in der weiterleitenden Ausführungseinheit gespeichert ist und die weiterleitende Ausführungseinheit die andere Ausführungseinheit in dem gesuchten Programmteil kennt. Hierdurch muss nicht bei jedem entfernten Zugriff (d. h. einem Zugriff auf einen Programmteil der auf einer anderen Ausführungseinheit gespeichert ist) auf ein Programmteil die globale Indirektionstabelle angesprochen werden. Darüber hinaus muss bei der Verlagerung eines Programmteils keine andere Ausführungseinheit über den neuen Speicherort des Programmteils informiert werden. Dieser wird durch den erstmaligen Aufruf auf das entfernte Programmteil automatisch aktualisiert.
  • Die Erfindung betrifft ferner ein Computerprogramm mit einem Programmcode zur Durchführung des beschriebenen Verfahrens, wenn das Programm auf einem Rechner mit einem Mehrkernprozessor abläuft. Das Computerprogramm kann auf einem Computerprogrammprodukt verwirklicht sein, welches in Gestalt einer Diskette, einer CD-ROM, einer DVD, einem USB-Speicher und dergleichen ausgebildet ist. Das Computerprogramm kann auch in Form eines über ein Netzwerk übertragbaren bzw. übertragenen Datensignals verwirklicht sein.
  • Die Erfindung schafft ferner einen Mehrkernprozessor mit einer Mehrzahl an Ausführungseinheiten, welche jeweils einen lokalen Speicher für die Speicherung eines oder mehrere Programmteile des Programms und zumindest eine kommunikativ mit dem lokalen Speicher verbundene Recheneinheit umfassen. Jede der Ausführungseinheiten ist zum Datenaustausch mit einem Kommunikationsnetzwerk verbunden. Der Mehrkernprozessor ist derart gesteuert, dass die Ausführung eines jeweiligen Programmteils des Programms durch die Recheneinheit derjenigen Ausführungseinheiten erfolgt, welche in ihrem lokalen Speicher das Programmteil gespeichert hat.
  • Der erfindungsgemäße Mehrkernprozessor weist die gleichen Vorteile auf, wie diese vorstehend in Verbindung mit dem erfindungsgemäßen Verfahren beschrieben wurden.
  • Ein erfindungsgemäßer Mehrkernprozessor zeichnet sich insbesondere dadurch aus, dass eine Ausführungskontexteinheit einer der Ausführungseinheiten dazu ausgebildet ist, zumindest einen Teil eines Ausführungskontextes des auf dieser Ausführungseinheit ausgeführten Programmteils auszulesen und an eine andere der Ausführungseinheiten zur Ausführung zu übertragen, wenn zur Ausführung dieses Pro grammteils der auf der anderen Ausführungseinheit gespeicherte Programmteil benötigt wird. Die Ausführungskontexteinheit kann durch Software realisiert werden, so dass das erfindungsgemäße Verfahren auf einem herkömmlichen Mehrkernprozessor ausführbar ist. Die Ausführungskontexteinheit wird bevorzugt in Hardware bereitgestellt, so dass die Performanz des Mehrkernprozessors optimal gesteigert werden kann. Der Ausführungskontext kann insbesondere einen Registersatz einschließlich eines Befehlszählers und einen Funktionsparameter umfassen.
  • Der erfindungsgemäße Mehrkernprozessor weist darüber hinaus weitere Mittel zur Durchführung des oben beschriebenen Verfahrens auf.
  • Die Erfindung wird nachfolgend anhand eines Ausführungsbeispiels näher erläutert. Es zeigen:
  • 1 eine schematische Darstellung eines erfindungsgemäßen Mehrkernprozessors,
  • 2 eine schematische Darstellung einer einzelnen Ausführungseinheit eines erfindungsgemäßen Mehrkernprozessors,
  • 3A einen Aufrufpfad von Programmteilen eines ersten Ausführungsstrangs,
  • 3B eine schematische Darstellung des in dem erfindungsgemäßen Mehrkernprozessor gemäß 1 ausgeführten ersten Ausführungsstrangs,
  • 4A einen Aufrufpfad von Programmteilen eines zweiten Ausführungsstrangs,
  • 4B eine schematische Darstellung des in dem erfindungsgemäßen Mehrkernprozessor gemäß 1 ausgeführten ersten und zweiten Ausführungsstrangs, und
  • 5 ein weiteres Ausführungsbeispiel eines erfindungsgemäßen Mehrkernprozessors mit heterogener Architektur.
  • 1 zeigt eine schematische Darstellung eines erfindungsgemäßen Mehrkernprozessors 1, wie dieser zur Durchführung des erfindungsgemäßen Verfahrens zum Einsatz kommen kann. Beispielhaft weist der erfindungsgemäße Mehrkernprozessor 1 vier Ausführungseinheiten 21, 22, 23, 24 auf. Eine Ausführungseinheit stellt einen Prozessorkern innerhalb des Mehrkernprozessors 1 dar. Jede der Ausführungseinheiten 21, 22, 23, 24 ist mit einem Kommunikationsnetzwerk 30 verbunden, welches in Gestalt eines Bussystems oder Network on a Chip (NoC) realisiert sein kann. Das Kommunikationsnetzwerk 30 ist in 1 aufgrund der matrixförmigen Anordnung der Ausführungseinheiten 21, 22, 23, 24 in Form eines Gitters ausgebildet, so dass räumlich benachbarte Ausführungseinheiten quasi direkt miteinander kommunizieren können. Der Aufbau des Mehrkernprozessors 1 entspricht damit dem bekannten Aufbau von Multi- oder Many-Core-Prozessoren mit einer größeren Anzahl an Prozessorkernen. Die Anzahl der in einem erfindungsgemäßen Mehrkernprozessor 1 vorgesehenen Ausführungseinheiten, deren räumliche Anordnung sowie die Art und Ausbildung des Kommunikationsnetzwerks 30 sind für die Durchführung des erfindungsgemäßen Verfahrens von untergeordneter Bedeutung, so dass hierauf nachfolgend nicht näher eingegangen wird.
  • Charakteristisch für eine Ausführungseinheit 21, 22, 23, 24 eines erfindungsgemäßen Mehrkernprozessors 1 ist der in 1 dargestellte, jeweils vorhandene lokale Speicher 201. Der lokale Speicher 201 kann als Cache-Speicher ausgebildet sein. Neben dem lokalen Speicher 201 weist jede der Ausführungseinheiten 21, 22, 23, 24 weitere Elemente auf, welche nachfolgend anhand der schematischen 2 näher erläutert werden.
  • Neben dem Speicher 201 weist die in 2 beispielhaft dargestellte Ausführungseinheit 21 in bekannter Weise eine Recheneinheit 202 auf. Die Recheneinheit 202 wird als Prozessorpipeline bezeichnet und weist in ebenfalls bekannter Weise einen Fetch 203, einen Decodierer 204, eine Ausführungseinheit der Recheneinheit 205 (Exe) sowie eine Write-Back-Einheit 206 auf. Die Ausführungseinheit 205 ist mit einem Register 207 und mit dem lokalen Speicher 201 verbunden. Von dem lokalen Speicher 201 können ferner in diesem enthaltene Daten dem Fetch 203 zugeführt werden. Als weitere Einheit ist neben der Recheneinheit oder als Bestandteil der Recheneinheit 202 eine sog. Ausführungskontexteinheit 210 vorgesehen. Die Ausführungskontexteinheit 210 steht kommunikativ mit dem Fetch 203 sowie dem Register 207 in Verbindung. Das Register 207 kann darüber hinaus Daten aus der Write-Back-Einrichtung 106 empfangen. Die Ausführungseinheit 21 ist über die Ausführungskontexteinheit 210 mit dem Kommunikationsnetzwerk 30 verbunden.
  • Das erfindungsgemäße Verfahren zum Ausführen eines Programmteile umfassenden Programms auf dem Mehrkernprozessor 1 mit den beschriebenen Ausführungseinheiten beruht nun darauf, nicht Programmteile (umfassend Code und Daten) zu einer Ausführungseinheit des Mehrkernprozessors zu transportieren, sondern die Ausführung an diejenige Ausführungseinheit zu verlagern, welche den auszuführenden Programmteil in ihrem lokalen Speicher enthalten hat. Durch diese Vermeidung des Transports von Programmteilen zum Ort der Ausführung wird nicht nur die Latenz bei der Ausführung des Programms verringert, sondern es wird auch das Kommunikationsnetzwerk entlastet.
  • Die Aufgabe der Ausführungskontexteinheit 210 besteht nun darin, den Ausführungskontext der jeweiligen Ausführungseinheit auszulesen, sofern die zur Bearbeitung des Programms notwendigen Programmteile nicht in dem lokalen Speicher 201 dieser Ausführungseinheit enthalten sind. Die Ausführungskontexteinheit 210 überträgt den Ausführungskontext, z. B. einen kompletten Registersatz inklusive Befehlszähler und/oder nur Funktionsparameter, an diejenige Ausführungseinheit des Mehr kernprozessors 1, welche die entsprechenden Programmteile gespeichert hat. Die Ausführungskontexteinheit 210 der empfangenen Ausführungseinheit transportiert die übermittelten Daten in die dortige Recheneinheit 202 und startet anschließend die Ausführung des entsprechenden Programmteils.
  • Das Verfahren lässt sich gut zusammen mit dem Paradigma der objektorientierten Programmierung anwenden, da bei einem Objekt Daten und Code in einer Beziehung stehen und entsprechend in einer Einheit gekapselt werden können. Insbesondere können Objekte in einem Mehrkernprozessor auf die lokalen Speicher der einzelnen Ausführungseinheiten abgelegt werden, wobei die Ausführung des Programms bei einem Methodenaufruf zu derjenigen Ausführungseinheit „springt”, die das Objekt (d. h. Code und Daten) in ihrem lokalen Speicher hält. Obwohl sich die Erfindung nicht nur bei objektorientierten Programmiersprachen anwenden lässt, wird nachfolgend zur einfacheren Beschreibung der Zusammenhänge auf diese Bezug genommen, wobei ein Objekt einem Programmteil eines Programms entspricht.
  • Die Objekte eines Programms, umfassend Code und Daten, werden zur Ausführungszeit auf den einzelnen Ausführungseinheiten 21, 22, 23, 24 in deren jeweiligen lokalen Speicher 201 abgelegt. Solange noch freier Speicher auf einer der Ausführungseinheiten 21, 22, 23, 24 vorhanden ist, können neue Objekte lokal erzeugt werden. Ist der lokale Speicher einer Ausführungseinheit 21, 22, 23, 24 erschöpft, werden neue Objekte auf anderen der Ausführungseinheiten erstellt und ein Verweis auf die entsprechende Ausführungseinheit hinterlegt. Wird nun ein Methodenaufruf auf einem entfernten Objekt ausgeführt, so wechselt die Ausführung durch Übermittlung einer Nachricht zu der das Objekt vorhaltende Ausführungseinheit und die Programmabarbeitung wird auf dieser Ausführungseinheit fortgesetzt. In der Nachricht müssen dazu die Referenz auf das Objekt, die Methode sowie die notwendigen Parameter übermittelt werden.
  • Die Funktionsweise der Erfindung wird nachfolgend an einem einfachen Beispiel anhand der 3A, 3B verdeutlicht. Anhand des unten dargestellten Programm ausschnitts wird deutlich, wie die Ausführung des Programms zwischen verschiedenen Ausführungseinheiten wechselt.
  • Figure 00150001
  • Figure 00160001
  • Das dargestellte Java-Programm besteht aus drei Klassen. Die main-Methode des Programms ist in der Klasse „ClassA” definiert, bei der die Programmausführung beginnt. ClassA definiert eine Instanz von ClassB (Zeile 6), auf der dann die Methode „method1” aufgerufen wird (Zeile 17). Die Klasse „ClassB” definiert ihrerseits eine Instanz der Klasse „ClassC” (Zeile 26) und ruft dort Methode „method2” auf (Zeile 32). Die Objekte, die Instanzen der Klassen darstellen, sind in dem Programm sowie in den 3 und 4 mit A, B und C bezeichnet.
  • Der Aufrufpfad zwischen den Objekten „objectA”, „objectB”, „objectC” (kurz: A, B, C) des obigen Programms ist in 3A dargestellt. Von dem Objekt A aus wird die Methode „method1” des Objekts B aufgerufen (Methodenaufruf MA1). Das Objekt B ruft seinerseits über den Methodenaufruf MA2 die Methode „method2” des Objekts C auf. Nachdem die Methode „method2” des Objekts C beendet wurde, kehrt die Ausführung zu Objekt B zurück (Methodenrücksprung MR2). Ist dort die Bearbeitung der Methode „method1” beendet, so kehrt die Ausführung schließlich zu Objekt A zurück (Methodenrücksprung MR1).
  • Angenommen, die Objekte A, B, C wären wie in 3B dargestellt, auf den vorhandenen Ausführungseinheiten 21, 22 und 23 verteilt, so ergibt sich für das Verfahren die Ausführungsreihenfolge 1. bis 4., welche jeweils neben den Methodenaufrufen MA1, MA2 bzw. Methodenrücksprüngen MR1, MR2 dargestellt sind. Die Ausführung des Programms startet beim Objekt A auf der Ausführungseinheit 21. Mit dem Aufruf der Methode „method1” auf Objekt B (1.) wechselt die Ausführung zur Ausführungseinheit 22. Von dort wird die Methode „method2” des Objekts C aufgerufen (2.) und die Ausführung wird auf der Ausführungseinheit 23 fortgesetzt. Nachdem die Methode des Objekts C ausgeführt wurde, kehrt die Ausführung zur Ausführungseinheit 22 zurück (3.) und nach Abarbeitung der Methode des Objekts B schließlich zur Ausführungseinheit 21 (4.).
  • Wird dasselbe Programm mit anderen Objekten beispielsweise durch einen zweiten Ausführungsstrang (sog. Thread) abgearbeitet, ergibt sich auch für diesen der gleiche Aufrufpfad wie für den ersten Ausführungsstrang. Die zugehörigen Objekte werden zur Unterscheidung mit A', B' und C' bezeichnet. 4A zeigt den zugehörigen Aufrufpfad, der im Übrigen dem in 3A gezeigten entspricht.
  • In 4B ist eine mögliche Konstellation dargestellt, wenn die zwei Ausführungsstränge gleichzeitig auf den Ausführungseinheiten 21, 22, 23, 24 des Mehrkernprozessors 1 abgearbeitet werden. Dabei wird angenommen, dass die Objekte A, B, C, A', B' und C' wie in 4B dargestellt, auf verschiedenen Ausführungsein heiten zur Laufzeit angelegt wurden. Zur besseren Übersicht sind die Methodenaufrufe MA1, MA2, MA1', MA2' sowie die Methodenrücksprünge MR1, MR2, MR1', MR2' jeweils nur mit einem Pfeil dargestellt. Aus 4B ist zu erkennen, wie die Ausführungsstränge unterschiedlicher Programme zwischen den Ausführungseinheiten 21, 22, 23, 24 springen. Wie insbesondere aus 4B ohne Weiteres ersichtlich ist, kann eine parallele Abarbeitung der Ausführungsstränge erfolgen. Wird davon ausgegangen, dass die Objekte A und A' in den Ausführungseinheiten 21, 23 zur gleichen Zeit gestartet werden, so kann die Ausführungseinheit 21 unmittelbar nach dem Methodenaufruf des Objekts B das von der Ausführungseinheit 23 aufgerufene Objekt B' abarbeiten usw.
  • Zu Beginn und während der Programmausführung müssen neue Objekte erstellt werden. Wie aus der Beschreibung bereits ersichtlich wurde, können Objekte solange auf einem der lokalen Speicher 201 der aktuellen Ausführungseinheit 21, 22, 23, 24 angelegt werden, bis dessen Kapazität erschöpft ist. Weitere Objekte können dann in einem lokalen Speicher 201 einer anderen Ausführungseinheit erstellt werden. Dabei können die neuen Objekte, in Abhängigkeit einer Optimierungsstrategie, an einer möglichst nahe gelegenen Ausführungseinheit erstellt werden, so dass die Kommunikationswege über das Kommunikationsnetzwerk 30 zur Übertragung der Ausführung so kurz wie möglich gehalten werden. Hierdurch können Latenzen bei der Ausführung klein gehalten werden.
  • Die Erzeugung neuer Ausführungsstränge kann auf mehrere Arten realisiert werden. Die einfachste Implementierung sieht die Erzeugung eines neuen Ausführungsstrangs auf der aktuellen Ausführungseinheit vor. Durch die Erzeugung und Nutzung von Objekten auf anderen Ausführungseinheiten springt die Ausführung dieses Ausführungsstrangs automatisch auf die anderen Ausführungseinheiten. Somit würden die Ausführungsstränge aufgrund der verteilten Erzeugung von Objekten automatisch in dem Mehrkernprozessor verteilt. Um bereits bei der Erzeugung neuer Ausführungsstränge einen höheren Grad an Parallelität zu erhalten, kann ein neuer Ausführungsstrang von vorne herein auf einer anderen Ausführungseinheit erstellt wer den. Damit würde, besonders bei einer größeren Anzahl von Ausführungssträngen, eine bessere Auslastung der vorhandenen Ausführungseinheiten erreicht werden. Eine hohe Lokalität der Objekte führt zu kurzen Kommunikationswegen und verringert somit die Latenzen bei der Programmausführung. Eine gute Verteilung der Ausführungsstränge erhöht den Grad der Parallelität.
  • Für den Fall, dass mehrere Ausführungsstränge auf einer Ausführungseinheit ausgeführt werden müssen, können Scheduling-Verfahren zum Einsatz kommen, um die vorhandene Zeit der Recheneinheit der Ausführungseinheit zwischen den Ausführungssträngen aufzuteilen. Der Vorteil bei der Ausführung mehrerer Ausführungsstränge besteht darin, dass keine Vorrichtung zur Synchronisation der Ausführungsstränge benötigt wird. Da jedes Objekt nur ein einziges Mal in dem Mehrkernprozessor vorhanden ist und der Zugriff darauf nur über die jeweilige Ausführungseinheit erfolgen kann, ist der exklusive Zugriff eines Ausführungsstrangs auf jedes beliebige Objekt garantiert. Kritische Wettläufe können somit nicht entstehen.
  • Ein weiterer Vorteil zeigt sich im Fall der Synchronisation von Ausführungssträngen durch Objekte. Möchte ein Ausführungsstrang Zugang zu einem durch ein Synchronisationsobjekt geschützten Programmteil erhalten, wechselt die Programmausführung zu der Ausführungseinheit, auf der die Methode zur Erlangung des Zugangs ausgeführt werden kann. Ist der Zugang möglich, kann die Programmausführung fortgesetzt werden und der Ausführungsstrang springt wieder zurück. Ist der Zugang nicht möglich, wird der Ausführungsstrang auf der Ausführungseinheit blockiert, auf der das Synchronisationsobjekt liegt. Somit braucht nicht der Zustand des Synchronisationsobjekts ständig zwischen verschiedenen Ausführungseinheiten hin- und hertransferiert werden. Stattdessen treffen sich die Ausführungsstränge, die um den Zutritt in den geschützten Bereich konkurrieren, bei der Ausführungseinheit, auf der das Synchronisationsobjekt liegt. Je mehr Ausführungsstränge durch ein solches Synchronisationsobjekt synchronisiert werden sollen, desto effizienter arbeitet das Verfahren im Vergleich zur herkömmlichen Organisation eines Mehrkernprozessors, bei der jeweils das Synchronisationsobjekt zu den Ausführungseinheiten transferiert werden muss.
  • In herkömmlichen Prozessoren ist das Auslagern von Daten und Code ein zeitaufwändiger Vorgang, da mit der nächsten Cache-Hierarchiestufe oder einem Hauptspeicher kommuniziert werden muss, welcher mit dem Mehrkernprozessor verbunden ist. Der Zugriff auf die deutlich langsameren Speicher erhöht die Latenzen bis zur Ausführung des nächsten Befehls und verringert dadurch die Ausführungsgeschwindigkeit eines Programms erheblich. Beim Einsatz des erfindungsgemäßen Verfahrens kann, bevor letztendlich in den Hauptspeicher oder eine höhere Cache-Hierarchiestufe ausgelagert werden muss, eine interne Umlagerungsstrategie benutzt werden. Der Grundgedanke ist dabei derselbe wie beim Erzeugen neuer Objekte oder Ausführungsstränge: Solange es noch freien Speicher auf einer der Ausführungseinheiten gibt, können Objekte auf andere Ausführungseinheiten verschoben werden, wo sie dann sofort wieder zur Verfügung stehen.
  • Die Ausführungsgeschwindigkeit von Programmen hängt maßgeblich davon ab, ob sich die benötigten Objekte im lokalen Speicher 201 der Ausführungseinheiten 21, 22, 23, 24 befinden. Da Objekte auch auf anderen Ausführungseinheiten erstellt werden können, kann es im Fall einer Schleife zu Leistungseinbußen kommen, wenn bei mehreren Durchläufen Methoden eines entfernten Objekts aufgerufen werden. Die Ausführung muss dann innerhalb eines begrenzten Bereichs sehr häufig zwischen mehreren Ausführungseinheiten verlegt werden. Eine Optimierung der Verteilung von Objekten kann durchgeführt werden, um Objekte an den Ort der Ausführung oder zumindest in deren Nähe zu verlegen. Stellt sich bei der Ausführung einer Methode heraus, dass bestimmte Objekte sehr häufig von einer Ausführungseinheit angesprochen werden, so können diese Objekte zur aufrufenden Ausführungseinheit transferiert werden, um die Ausführung lokal zu halten.
  • Können die benötigten Objekte nicht alle auf eine Ausführungseinheit verlegt werden, so ist es zweckmäßig, die betreffenden Daten so nahe wie möglich an die aus führende Ausführungseinheit zu verlegen, um die Kommunikationswege zu minimieren und dadurch die Ausführungslatenzen zu reduzieren.
  • Der lokal verfügbare Speicher begrenzt die Ausführungsgeschwindigkeit einer Ausführungseinheit. Werden andere Objekte, als die lokal verfügbaren Objekte benötigt, muss ausgelagert werden, um Platz für die benötigten Objekte zu schaffen. Für speicherintensive Programme bietet sich hier die Möglichkeit, eine heterogene Architektur in dem Mehrkernprozessor zu schaffen, die neben den Ausführungseinheiten 40 zusätzliche Speichereinheiten 50 besitzt, in die Objekte sehr schnell verschoben werden können. Für die Ausführung müssen diese Objekte wieder in eine der Ausführungseinheiten 40 zurückverschoben werden. In 5 ist ein Beispiel einer derartigen heterogenen Architektur eines Mehrkernprozessors 1 dargestellt. Wird in vertikaler und horizontaler Richtung jeweils nach einer Ausführungseinheit 40 eine Speichereinheit 50 eingebaut, so hat jede Ausführungseinheit auf mindestens zwei benachbarte Speichereinheiten 50 Zugriff, in die sehr schnell Objekte verlagert werden können. Durch den zusätzlichen Speicher auf dem Prozessor, kann eine Auslagerung von Objekten in den Hauptspeicher länger vermieden werden, was zu einer Steigerung der Ausführungsgeschwindigkeit führt.
  • Der Vorteil der heterogenen Architektur liegt darin, dass auch eine andere Ausführungseinheit, als die, die ein Objekt ausgelagert hat, schnell das ausgelagerte Objekt einlagern kann. Insbesondere können benachbarte Ausführungseinheiten, aufgrund der kurzen Kommunikationswege, sehr schnell Objekte austauschen. Da jeweils nur ein Ausführungsstrang gleichzeitig auf einem Objekt arbeiten kann, werden für die Speichereinheiten keine zusätzlichen Konsistenzverfahren benötigt.
  • Für spezielle Anwendungen oder Prozessorvarianten sind auch andere Konstellationen vorstellbar. Beispielsweise könnte es für Anwendungen mit einem hohen Datendurchsatz sinnvoll sein, an die Randbereiche des Prozessors mehrere Speichereinheiten zu legen, um den Datentransfer zwischen Hauptspeicher und Ausführungseinhei ten in Richtung Mitte des Prozessors über mehrere Cache-Stufen zu Puffern und damit zu beschleunigen.
  • Ein Effekt beim Einsatz des erfindungsgemäßen Verfahrens ist, dass die Objekte eines Programms auf den Ausführungseinheiten verteilt werden können. Durch die Verteilung der Objekte ist aber zunächst nur für den Erzeuger die aktuelle Position des Objekts bekannt. Möchte ein anderer Ausführungsstrang auf dasselbe Objekt zugreifen, muss er die Adresse des Objekts, bestehend aus der Kennung der Ausführungseinheit und der lokalen Speicheradresse des Objekts, erfragen.
  • Hierzu kann eine globale Indirektionstabelle in einem Hauptspeicher, welcher mit dem Mehrkernprozessor gekoppelt ist, benutzt werden. Die globale Indirektionstabelle bildet die virtuellen Adressen der Objekte auf die physikalischen Adressen der Ausführungseinheit und der Objekte im lokalen Speicher ab. Wird ein Objekt anhand seiner Speicheradresse gesucht, kann dies durch einen Zugriff auf die globale Indirektionstabelle beantwortet werden. Um den Vorgang der Adressberechnung zu beschleunigen, kann ein hierarchisches Verfahren eingesetzt werden. Kleinere Tabellen auf dem Mehrkernprozessor speichern die am häufigsten erfragten Objektadressen. Wird ein Eintrag in der prozessoreigenen Indirektionstabelle nicht gefunden, wird der Eintrag in der globalen Indirektionstabelle im Hauptspeicher ermittelt.
  • Die Lokalisierung von Objekten kann weiterhin durch ein Pointer-Routing-Verfahren optimiert werden. Beim Pointer-Routing merkt sich eine Ausführungseinheit A die Adressen der ihr bekannten Objekte, auch derer, die auf anderen Ausführungseinheiten angeordnet sind. Wird ein Objekt von einer anderen Ausführungseinheit B auf eine weitere Ausführungseinheit C verschoben, so bekommt das die Ausführungseinheit A nicht mit und behält somit den falschen Zeiger. Beim nächsten Aufruf der Ausführungseinheit A einer Methode des verschobenen Objekts leitet Ausführungseinheit B die Ausführungsanfrage an eine Ausführungseinheit C weiter, wo die Ausführung dann letztendlich stattfindet. Durch die direkte Rückmeldung nach der Ausführung der Ausführungseinheit C an die Ausführungseinheit A wird die Adressliste in der Ausführungseinheit A aktualisiert. Nachfolgende Methodenaufrufe auf das Objekt können jetzt direkt an die Ausführungseinheit C übertragen werden.
  • Hierdurch muss nicht bei jedem entfernten Zugriff auf ein Objekt die globale Indirektionstabelle angesprochen werden. Darüber hinaus muss beim Verschieben eines Objekts keine andere Ausführungseinheit über die neue Adresse des Objekts informiert werden. Die neue Adresse wird durch erstmaligen Aufruf einer Methode auf das entfernte Objekt automatisch aktualisiert.
  • Die Leistungssteigerung, die durch das erfindungsgemäße Verfahren erreicht wird, liegt unter anderem darin begründet, dass die Ausführung der Ausführungsstränge auf den Ausführungseinheiten mit geringeren Latenzen erfolgt als bei herkömmlichen Verfahren, bei denen Code und Daten zu den entsprechenden Ausführungseinheiten transferiert werden müssen. Neben der Reduzierung der Latenzen bei der Ausführung ist auch eine bessere Nutzung der lokalen Speicher möglich, da neue Objekte im lokalen Speicher auf anderen Ausführungseinheiten erstellt werden können. Wie hoch die Leistungssteigerung genau ist, hängt stark vom jeweiligen Fall ab.
  • Ein Rechenbeispiel soll einen Vergleich zwischen einem herkömmlichen und dem Verfahren der Erfindung verdeutlichen. Als Beispiel wird ein Methodenaufruf angenommen, bei dem das Objekt und die Daten nicht im lokalen Speicher der aktuellen Ausführungseinheit vorhanden sind.
  • Herkömmliches Verfahren
  • Wird auf einer Ausführungseinheit ein Methodenaufruf ausgeführt, kommt es zu einem sog. Cache-Miss. Die Ausführungseinheit stellt eine Anfrage, um die benötigten Daten zu erhalten. Es wird davon ausgegangen, dass sich die Daten in einem lokalen Speicher einer anderen Ausführungseinheit befinden und von dort übertragen werden können. Befinden sich die Daten im Hauptspeicher, würde der Vorgang er heblich länger dauern, da der Hauptspeicher normalerweise langsamer getaktet wird als ein Cache-Speicher auf einem Prozessor.
  • Alle Kommandos, sowohl Anfragen als auch Antworten, werden in Form von Nachrichten verschickt, denen ein entsprechendes Code-Wort mit 1 Byte Länge vorangestellt ist. Die Anfrage enthält die Adresse der Objekt-Daten die zur Ausführung der Methode benötigt werden. Die Antwort enthält eine sog. Cache-Line mit 64 Byte, die mindestens den Anfang der Methode des Objekts enthält. Für die Anfrage werden 5 Bytes (Code: 1 Byte; Adresse: 4 Byte) und für die Antwort 65 Bytes (Code: 1 Byte; Cache-Line: 64 Byte) benötigt. Insgesamt müssen beim herkömmlichen Verfahren somit mindestens 70 Byte übertragen werden. Werden neben den Daten auch der Code benötigt (wie oben angenommen), müssen mindestens weitere 70 Byte an Code zwischen den Ausführungseinheiten übertragen werden. Die 140 Byte stellen somit die minimale Anzahl an Bytes dar, die im herkömmlichen Fall übertragen werden müssen.
  • Erfindungsgemäßes Verfahren
  • Beim erfindungsgemäßen Verfahren wird die Ausführung des Programms an eine andere Ausführungseinheit übertragen. Dazu müssen ein Kontextzeiger (CTX), die Adresse der Ausführungseinheit (in X, Y Position), die Adresse des Objekts, die Kennung der Methode und die Parameter übertragen werden. Es wird davon ausgegangen, dass im Schnitt drei Parameter bei einem Methodenaufruf übergeben werden. Für die Rückübertragung der Ausführung und des Ergebnisses müssen der Kontextzeiger, die Adresse der Ausführungseinheit und das Ergebnis übertragen werden. Für die Übertragung der Ausführung werden 25 Byte (Code: 1 Byte; CTX: 4 Byte; X: 1 Byte; Y: 1 Byte; Objekt: 4 Byte; Methode: 2 Byte; drei Parameter: 12 Byte) benötigt. Für die Rückübertragung der Ausführung werden 11 Byte (Code: 1 Byte; CTX: 4 Byte; X: 1 Byte; Y: 1 Byte; Ergebnis: 4 Byte) benötigt. Im erfindungsgemäßen Fall müssen somit durchschnittlich nur 25 Byte für den Wechsel der Ausführung zu einer anderen Ausführungseinheit übertragen werden und 11 Byte für die Rück übertragung der Ausführung, sofern ein Ergebnis übermittelt werden muss. Wird kein Ergebnis erwartet, werden lediglich 7 Byte für die Rückübertragung der Ausführung benötigt, insgesamt somit 32 Byte.
  • Wie der Vergleich zeigt, ergibt sich bereits dann eine um 74% geringere Belastung des Kommunikationsmediums, wenn für das herkömmliche Verfahren der Optimalfall und das erfindungsgemäße Verfahren der Normalfall angenommen wird. Sollte die Methode aus mehr als 64 Byte Code bestehen, müssen möglicherweise noch weitere Cache-Lines geholt werden und das Kommunikationsmedium wird zusätzlich belastet, was im vorliegenden Fall der Erfindung nicht notwendig ist. Durch die geringere Anzahl an Bytes, die zur Übertragung der Ausführung bei der Erfindung benötigt werden, entsteht zusätzlich eine geringere Latenz, bis die Ausführung fortgesetzt werden kann.
  • Das erfindungsgemäße Verfahren reduziert somit nicht nur die Latenzen bei der Ausführung von Programmen, sondern entlastet zusätzlich das Kommunikationsmedium. Die genaue Höhe der Leistungssteigerung hängt vom konkreten Anwendungsfall ab.
  • 1
    Mehrkernprozessor
    21
    Ausführungseinheit
    22
    Ausführungseinheit
    23
    Ausführungseinheit
    24
    Ausführungseinheit
    30
    Kommunikationsnetzwerk
    40
    Ausführungseinheit
    50
    Speicher
    201
    lokaler Speicher
    202
    Recheneinheit (Prozessorpipeline)
    203
    Fetch
    204
    Dekodierer
    205
    Ausführungseinheit der Recheneinheit
    206
    Write Back
    207
    Register
    210
    Ausführungskontexteinheit (Motion Unit)
    A
    Objekt
    B
    Objekt
    C
    Objekt
    A'
    Objekt
    B'
    Objekt
    C'
    Objekt
    MA1
    Methodenaufruf
    MR1
    Methodenrücksprung
    MA2
    Methodenaufruf
    MR2
    Methodenrücksprung
    MA1'
    Methodenaufruf
    MR1'
    Methodenrücksprung
    MA2'
    Methodenaufruf
    MR2'
    Methodenrücksprung

Claims (20)

  1. Verfahren zum Ausführen eines Programmteile umfassenden Programms auf einem Mehrkernprozessor (1) mit einer Mehrzahl an Ausführungseinheiten (21, 22, 23, 24), welche jeweils einen lokalen Speicher (201) und zumindest eine kommunikativ mit dem lokalen Speicher verbundene Recheneinheit (202) umfassen, wobei jede der Ausführungseinheiten (21, 22, 23, 24) zum Datenaustausch mit einem Kommunikationsnetzwerk (30) verbunden ist, bei dem – ein oder mehrere Programmteile des Programms in zumindest manche der lokalen Speicher (201) der Mehrzahl an Ausführungseinheiten (21, 22, 23, 24) eingespeichert werden; – die Ausführung eines jeweiligen Programmteils des Programms durch die Recheneinheit (202) derjenigen Ausführungseinheit (21, 22, 23, 24) erfolgt, welche in ihrem lokalen Speicher (201) das Programmteil gespeichert hat.
  2. Verfahren nach Anspruch 1, bei dem eine Ausführungskontexteinheit (210) einer der Ausführungseinheiten (21, 22, 23, 24) zumindest einen Teil eines Ausführungskontextes, insbesondere einen Registersatz einschließlich eines Befehlszählers und Funktionsparameter, des auf dieser Ausführungseinheit (21, 22, 23, 24) ausgeführten Programmteils ausliest und an eine andere der Ausführungseinheiten (21, 22, 23, 24) zur Ausführung überträgt, wenn zur Ausführung dieses Programmsteils der auf der anderen Ausführungseinheit (21, 22, 23, 24) gespeicherte Programmteil benötigt wird.
  3. Verfahren nach Anspruch 1 oder 2, bei dem das Programm aus einer objektorientierten Programmiersprache erzeugt wird, wobei Objekte und zu einer Klasse der Objekte gehörender Programmcode des Programms auf zumindest manchen der Ausführungseinheiten (21, 22, 23, 24) in deren lokalen Speicher (201) abgelegt werden.
  4. Verfahren nach einem der vorherigen Ansprüche, bei dem die Programmteile zur Laufzeit des Programms in einen jeweiligen lokalen Speicher (201) der Mehrzahl an Ausführungseinheiten (21, 22, 23, 24) eingespeichert werden.
  5. Verfahren nach einem der vorherigen Ansprüche, bei dem ein in den lokalen Speicher (201) einer ersten Ausführungseinheit (21, 22, 23, 24) einzuspeichernder Programmteil in den lokalen Speicher (201) einer zweiten, vorzugsweise räumlich benachbarten, Ausführungseinheit (21, 22, 23, 24) eingespeichert wird, wenn der lokale Speicher (201) der ersten Ausführungseinheit (21, 22, 23, 24) erschöpft ist.
  6. Verfahren nach Anspruch 5, bei dem in dem lokalen Speicher (201) der ersten Ausführungseinheit (21, 22, 23, 24) optional ein Verweis auf den Programmteil in der zweiten Ausführungseinheit (21, 22, 23, 24) vorgesehen wird.
  7. Verfahren nach Anspruch 5 oder 6, bei dem zeitlich ältere Programmteile in einen insbesondere außerhalb des Mehrkernprozessors (1) vorgesehenen Speicher, insbesondere einen Cache-Speicher, ausgelagert werden, wenn die lokalen Speicher (201) der Ausführungseinheiten (21, 22, 23, 24) ein Einspeichern neuer Programmteile nicht mehr erlauben.
  8. Verfahren nach Anspruch 7, bei dem überprüft wird, ob ein Programmteil von dem lokalen Speicher (201) einer ersten Ausführungseinheit (21, 22, 23, 24) in den lokalen Speicher (201) einer zweiten Ausführungseinheit (21, 22, 23, 24) verschoben werden kann, bevor das Programmteil in den außerhalb des Mehrkernprozessors vorgesehenen Speicher verschoben wird.
  9. Verfahren nach einem der vorherigen Ansprüche, bei dem ein Programmteil von dem lokalen Speicher (201) einer ersten Ausführungseinheit (21, 22, 23, 24) in den lokalen Speicher (201) einer zweiten, das Programm ausführenden oder in den lokalen Speicher (201) einer dritten Ausführungseinheit (21, 22, 23, 24) verschoben wird, welche räumlich nahe zu der zweiten Ausführungseinheit (21, 22, 23, 24) gelegen ist.
  10. Verfahren nach einem der vorherigen Ansprüche, bei dem die Erzeugung eines neuen Ausführungsstrangs auf der zur Laufzeit genutzten Ausführungseinheit (21, 22, 23, 24) oder einer davon verschiedenen Ausführungseinheit (21, 22, 23, 24) erfolgt.
  11. Verfahren nach Anspruch 10, bei dem bei der Ausführung mehrerer Ausführungsstränge auf einer Ausführungseinheit (21, 22, 23, 24) ein erstes Prozess-Steuerprogramm, insbesondere in der Ausführungskontexteinheit (210) dieser Ausführungseinheit (21, 22, 23, 24), vorgesehen ist, um die vorhandene Zeit der Recheneinheit (202) zwischen den Ausführungssträngen aufzuteilen.
  12. Verfahren nach einem der vorherigen Ansprüche, bei dem in einer jeweiligen Ausführungseinheit (21, 22, 23, 24), insbesondere in der Ausführungskontexteinheit (210) der Ausführungseinheit (21, 22, 23, 24), ein zweites Prozess-Steuerprogramm vorgesehen ist zur Verwaltung einer Mehrzahl an Ausführungsanfragen für ein und denselben Programmteil in der betreffenden Ausführungseinheit (21, 22, 23, 24).
  13. Verfahren nach einem der vorherigen Ansprüche, bei dem in einer jeweiligen Ausführungseinheit (21, 22, 23, 24), insbesondere in der Ausführungskontexteinheit (210) der Ausführungseinheit (21, 22, 23, 24), eine Look-up-Tabelle vorgesehen ist.
  14. Verfahren nach einem der vorherigen Ansprüche, bei dem in einem außerhalb des Mehrkernprozessors (1) vorgesehenen und mit dem Mehrkernprozessor (1) in Kommunikationsverbindung stehenden Hauptspeicher eine globale Indirektionstabelle vorgesehen wird, welche virtuelle Adressen der Programmteile auf die physikalischen Adressen jeweiliger lokaler Speicher (201) der Ausführungseinheiten (21, 22, 23, 24) abbildet.
  15. Verfahren nach Anspruch 14, bei dem ein Teil der in der Indirektionstabelle zu speichernden Information in den jeweiligen lokalen Speichern (201) der Ausführungseinheiten (21, 22, 23, 24) vorgehalten wird.
  16. Verfahren nach einem der vorherigen Ansprüche, bei dem zur Lokalisierung eines Programmteils ein Pointer Routing-Verfahren eingesetzt wird, bei dem eine Ausführungsanfrage betreffend eines gesuchten Programmteils von einer Ausführungseinheit (21, 22, 23, 24) an eine andere Ausführungseinheit (21, 22, 23, 24) weitergeleitet wird, wenn der gesuchte Programmteil nicht in der weiterleitenden Ausführungseinheit (21, 22, 23, 24) gespeichert ist und die weiterleitende Ausführungseinheit (21, 22, 23, 24) die andere Ausführungseinheit (21, 22, 23, 24) mit dem gesuchten Programmteil kennt.
  17. Computerprogramm mit einem Programmcode zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 16, wenn das Programm auf einem Rechner mit einem Mehrkernprozessor abläuft.
  18. Mehrkernprozessor (1) mit einer Mehrzahl an Ausführungseinheiten (21, 22, 23, 24), welche jeweils einen lokalen Speicher (201) für die Speicherung eines oder mehrerer Programmteile des Programms und zumindest eine kommunikativ mit dem lokalen Speicher verbundene Recheneinheit (202) umfassen, wobei jede der Ausführungseinheiten (21, 22, 23, 24) zum Datenaustausch mit einem Kommunikationsnetzwerk (30) verbunden ist und der Mehrkernprozessor (1) derart gesteuert ist, dass die Ausführung eines jeweiligen Programmteils des Programms durch die Recheneinheit derjenigen Ausführungseinheit (21, 22, 23, 24) erfolgt, welche in ihrem lokalen Speicher (201) das Programmteil gespeichert hat.
  19. Mehrkernprozessor nach Anspruch 18, bei dem eine Ausführungskontexteinheit (210) einer der Ausführungseinheiten (21, 22, 23, 24) dazu ausgebildet ist, zumindest einen Teil eines Ausführungskontextes, insbesondere einen Registersatz einschließlich eines Befehlszählers, Funktionsparameter, des auf dieser Ausführungseinheit (21, 22, 23, 24) ausgeführten Programmteils auszulesen und an eine andere der Ausführungseinheiten (21, 22, 23, 24) zur Ausführung zu übertragen, wenn zur Ausführung dieses Programmsteils der auf der anderen Ausführungseinheit (21, 22, 23, 24) gespeicherte Programmteil benötigt wird.
  20. Mehrkernprozessor nach Anspruch 18 oder 19, bei dem dieser weitere Mittel zur Durchführung eines Verfahrens gemäß einem der Ansprüche 3 bis 16 aufweist.
DE102009004810A 2009-01-13 2009-01-13 Verfahren zum Ausführen eines oder mehrerer Programme auf einem Mehrkernprozessor und Mehrkernprozessor Ceased DE102009004810A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102009004810A DE102009004810A1 (de) 2009-01-13 2009-01-13 Verfahren zum Ausführen eines oder mehrerer Programme auf einem Mehrkernprozessor und Mehrkernprozessor
US12/685,416 US20100180101A1 (en) 2009-01-13 2010-01-11 Method for Executing One or More Programs on a Multi-Core Processor and Many-Core Processor

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102009004810A DE102009004810A1 (de) 2009-01-13 2009-01-13 Verfahren zum Ausführen eines oder mehrerer Programme auf einem Mehrkernprozessor und Mehrkernprozessor

Publications (1)

Publication Number Publication Date
DE102009004810A1 true DE102009004810A1 (de) 2010-07-15

Family

ID=42243671

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102009004810A Ceased DE102009004810A1 (de) 2009-01-13 2009-01-13 Verfahren zum Ausführen eines oder mehrerer Programme auf einem Mehrkernprozessor und Mehrkernprozessor

Country Status (2)

Country Link
US (1) US20100180101A1 (de)
DE (1) DE102009004810A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8949414B2 (en) * 2010-12-29 2015-02-03 Citrix Systems, Inc. Systems and methods for scalable N-core stats aggregation
US8806503B2 (en) * 2011-01-24 2014-08-12 Nec Laboratories America, Inc. Method and system for memory aware runtime to support multitenancy in heterogeneous clusters
IN2013CH04449A (de) 2013-09-30 2015-04-03 Empire Technology Dev Llc
WO2015047427A1 (en) * 2013-09-30 2015-04-02 Empire Technology Development, Llc Data transfer in a multi-core processor
WO2015185071A1 (en) * 2014-06-04 2015-12-10 Giesecke & Devrient Gmbh Method for enhanced security of computational device with multiple cores

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060112227A1 (en) * 2004-11-19 2006-05-25 Hady Frank T Heterogeneous processors sharing a common cache
US20060143408A1 (en) * 2004-12-29 2006-06-29 Sistla Krishnakanth V Efficient usage of last level caches in a MCMP system using application level configuration

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070124728A1 (en) * 2005-11-28 2007-05-31 Mark Rosenbluth Passing work between threads

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060112227A1 (en) * 2004-11-19 2006-05-25 Hady Frank T Heterogeneous processors sharing a common cache
US20060143408A1 (en) * 2004-12-29 2006-06-29 Sistla Krishnakanth V Efficient usage of last level caches in a MCMP system using application level configuration

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Kavaldjiev, N.K.: A run-time reconfigurable Network-on-Chip for streaming DSP applications. PhD thesis, University of Twente. CTIT PhD.-thesis series No. 06-91 ISBN 90-365-2410-5, 2007 *

Also Published As

Publication number Publication date
US20100180101A1 (en) 2010-07-15

Similar Documents

Publication Publication Date Title
DE69822534T2 (de) Gemeinsame Speicherbenutzung mit variablen Blockgrössen für symmetrische Multiporzessor-Gruppen
DE102009023898B4 (de) Optimierung von gleichzeitigen Zugriffen in einem verzeichnisbasierten Kohärenzprotokoll
DE60204687T2 (de) Speicherkopierbefehl mit Angabe von Quelle und Ziel, der in der Speichersteuerung ausgeführt wird
DE69434728T2 (de) Synchronisationssystem und verfahren in einem datencachesystem mit aufgeteiltem pegel
DE19807872A1 (de) Verfahren zur Verwaltung von Konfigurationsdaten in Datenflußprozessoren sowie Bausteinen mit zwei- oder mehrdimensionalen programmierbaren Zellstruktur (FPGAs, DPGAs, o. dgl.
DE102006032832A1 (de) Netzwerksystem und Verfahren zur Steuerung verteilter Speicher
DE102014000372A1 (de) Verbesserte steuerung des prefetch-traffics
DE4335475A1 (de) Datenverarbeitungseinrichtung mit Cache-Speicher
DE1815234A1 (de) Adressiereinrichtung fuer ein Speichersystem mit einem Grossraumspeicher und einem schnellen Arbeitsspeicher
DE2847216A1 (de) Datenverarbeitungssystem mit mehrprogrammbetrieb
DE102013202173A1 (de) Einheitliche Lade-Verarbeitung für Teilsätze von parallelen Threads
DE102013006396A1 (de) Eine grafikverarbeitungseinheit, in der eine standardverarbeitungseinheit verwendet ist, und ein verfahren zum aufbau einer grafikverarbeitungseinheit
DE112005003243T5 (de) System und Verfahren für die Cache-Kohärenz bei einem Cache mit unterschiedlichen Längen für die Cache-Orte
DE102009053578A1 (de) Verfahren und Vorrichtung zum Durchführen eines parallelen Routens unter Verwendung einer Multithreaded-Routing-Prozedur
DE102013018135B4 (de) Adressenbit-Wiederabbildungsschema zur Reduzierung einer Zugriffsauflösung von DRAM-Zugriffen
DE102012210895A1 (de) Vorhersage der ungeordneten Parallelverarbeitung der Befehle von Threads in einem Multithread-Prozessor
DE102013020967B4 (de) Technik zur Ausführung von Speicherzugriffsoperationen über eine Textur-Hardware
DE102009004810A1 (de) Verfahren zum Ausführen eines oder mehrerer Programme auf einem Mehrkernprozessor und Mehrkernprozessor
DE112005003222T5 (de) Dynamische Allokation eines Puffers auf mehrere Klienten bei einem Prozessor mit Threads
DE2164793A1 (de) Verfahren und Datenverarbeitungsanlage zur Steuerung einer Vielzahl von Eingabe/ Ausgabe-Einheiten mittels eine Zentraleinheit
DE112014000340T5 (de) Vorablesezugriff auf Daten für einen Chip mit einem übergeordneten Kern und einem Scout-Kern
DE19957594B4 (de) Verfahren zum Synchronisieren von threads eines Computerprogramms
EP1079307B1 (de) Verfahren zum Betrieb eines Speichersystems sowie Speichersystem
DE102012222391B4 (de) Mehrkanal-Zeitscheibengruppen
DE102004012516A1 (de) Computersystem zur elektronischen Datenverarbeitung

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final

Effective date: 20140515