Message Passing Interface

Embedded-Protokoll MCAPI trägt die Last in Multicore-Netzen

Seite: 2/3

Anbieter zum Thema

Symmetric Multiprocessing weist Limitierungen auf

Durch die architektonische Homogenität eines SMP-Multikernsystems ist dies recht einfach. Eine einzige Instanz des Betriebssystems durchläuft eine Gruppe von Prozessorkernen und verwaltet sie als Menge identischer Ressourcen. Ein Prozess wird daher in natürlicher Weise über mehrere Kerne verteilt. Ist der Prozess multi-threaded, dann kann er den Vorteil mehrerer Kerne nutzen, um die Verarbeitungsgeschwindigkeit zu erhöhen. Das geschieht ohne weiteres Zutun.

Allerdings nimmt bei SMP die Effektivität mit steigender Anzahl der Kerne ab – aufgrund der steigenden Auslastung des Systembusses und des Speicherzugriffs. Um SMP-Limitierungen zu vermeiden, können wir in Systemen mit sehr vielen Prozessorkernen AMP verwenden.

Bei AMP führt jeder Prozessorkern (oder eine Untergruppe von Kernen) jeweils eine unabhängige Instanz des Betriebssystems aus. Manche Kerne haben vielleicht kein Betriebssystem, sondern arbeiten Prozesse direkt auf der Hardware ab. Da ein Prozess nicht über mehrere Betriebssysteminstanzen verteilt sein kann, führt jede Instanz - und potenziell jeder Kern - die eigenen Prozesse aus. Deshalb kann sich eine SMP-Konfiguration wie ein einzelner Prozess darstellen, wogegen eine AMP-Konfiguration wie viele Prozesse aussieht - auch wenn es mehrere Instanzen des gleichen Prozesses sind.

MPI ist für die Kommunikation im Server überdimensioniert

Derart konfiguriert, muss jedes Betriebssystem eine eigene Instanz des MPI ausführen, um sicherzustellen, dass die eigenen Prozesse im Netzwerk repräsentiert sind und alle für sie adressierten Nachrichten an sie weitergeleitet werden. Das Problem ist: Das MPI ist unter den Protokollen ein Schwergewicht - aufgrund der Vielzahl an Situationen, die es auf dem Netzwerk verwalten können muss. Die Umgebung, in der die Prozessorkerne innerhalb des Computergehäuses oder sogar auf einem einzigen Prozessorchip miteinander verbunden sind, ist aber viel limitierter als das Netzwerk, in dem das MPI arbeiten muss. Diese Umgebung hat auch typischerweise wesentlich weniger Ressourcen als ein Netzwerk. Daher ist MPI für die Kommunikation innerhalb eines Servers überdimensioniert.

Die Multicore Association hat die MCAPI-Spezifikation leichtgewichtig ausgelegt, um die Interprozesskommunikation in Embedded-Systemen bedienen zu können, die oft geringe Ressourcen zur Verfügung haben. Während MCAPI anders als MPI funktioniert, stellt es dennoch einfache Mittel zur Verfügung, um Nachrichten von einem Prozessorkern zum nächsten zu transportieren. Dadurch können wir MCAPI nutzen, um MPI-Funktionalität zur Verfügung zu stellen.

Beschleuniger-Kerne führen das leichte Protokoll aus

Es gibt zwei mögliche Ansätze, um MCAPI in ein MPI-Design einzubringen. Der erste Weg funktioniert, wenn das Programm, das MPI nutzt, nur wenige seiner Konstrukte benötigt - mehr oder weniger nur das Senden und Empfangen simpler Nachrichten. Ein Master-Kern innerhalb des Servers führt den vollständigen MPI-Dienst sowie einen Übersetzer für alle anderen Beschleuniger-Kerne (Accelerator Cores) im Server aus. Die Beschleuniger-Kerne führen MCAPI anstatt des MPI aus. Das heißt, dass das MPI Nachrichten zwischen den Serversystemen austauscht, aber MCAPI die Meldungen zwischen den Kernen im Server transportiert.

Für Programminstanzen auf Beschleuniger-Kernen ersetzt man nun die MPI-Aufrufe mit den äquivalenten MCAPI-Calls. Das ist aber nur für einfache Anwendungsfälle des MPI möglich, da es für viele MPI-Konstrukte keine MCAPI-Äquivalente gibt. Ein Übersetzer konvertiert alle Nachrichten zwischen den MPI- und MCAPI-Domänen.

Der Preis dafür ist die Notwendigkeit, das Programm zu modifizieren und zu rekompilieren, um MCAPI anstelle von MPI für die Beschleuniger-Kerne zu verwenden. Auch die Wartung wird komplizierter, da nun zwei Versionen des Programms existieren - eine für MPI und eine für MCAPI.

Auf Seite 3: Tunneling und Vermittlung über mehrere Wege

(ID:29116650)