Ein erfolgreicher Entwicklungsprozess für Multicore-Software sollte die folgenden vier Schritte durchlaufen.
Design
Beim Design von Embedded-Software für Multicore-Prozessoren müssen besondere Überlegungen angestellt werden. Ein Problem entsteht, wenn die ersten Schritte beim Durchdenken/Implementieren einer Applikation/eines Algorithmus sequenziell angegangen werden. Dieses Verarbeitungsmodell bewährt sich bei einem Single-Core-System. Wenn die Komplexität einer Applikation allerdings die Performance-Reserven einer Single-Core-CPU überfordert, ist der Umstieg auf ein Multi core-System unumgänglich. Zunächst müssen die Bereiche identifiziert werden, die sich für die parallele Verarbeitung durch mehrere Cores anbieten. In einigen Fällen kann diese Aufgabe von den Applikations- bzw. Algorithmendesignern auf manuellem Weg erledigt werden. In den vergangenen Jahren sind jedoch kommerzielle Tools wie etwa Prism von CriticalBlue herausgekommen, die den Entwicklern diese Arbeit bei komplexen Anwendungen erleichtern.Für die optimale Zuordnung der parallel zu verarbeitenden Blöcke zu den einzelnen Cores sind sowohl die Kommunikationsanforderungen zwischen den parallel verarbeiteten Blöcken als auch die Ein- und Ausgabeschnittstellen zu berücksichtigen. Müssen die Blöcke häufig miteinander kommunizieren und wird diese Kommunikation von der gewählten Multicore-Architektur effektiv unterstützt, steht der Verarbeitung durch verschiedene Cores nichts entgegen. Stellt sich allerdings die Kommunikation zwischen den Cores als Engpass heraus und kommt der Wechsel auf eine andere, effizientere Prozessarchitektur nicht in Betracht, muss der Entwickler wieder auf die Segmentierungs-Methode zurückgreifen und geeignete Parallelisierungs-Strategien ausfindig machen. Ein wichtiger Faktor ist auch die mögliche gemeinsame Nutzung von peripheren Schnittstellen. Sobald zwei parallel verarbeitete Blöcke dieselbe E/A-Schnittstelle nutzen, muss beim Design besondere Sorgfalt angewandt werden. Die effektive Modellierung eines solchen Verhaltens mithilfe eines Simulators oder unter Einsatz von Tools wie Poly-Platform von Polycore Software hilft in dieser Phase beim Design paralleler Software, die nur in geringem Maße anfällig für Engpässe bei der Multicore-Kommunikation oder den E/A-Ressourcen ist.
Entwicklung
Entwicklungs-Teams müssen sich im Zusammenhang mit Multicore-Prozessoren eines gemeinsamen Programmiermodells bedienen und auf Konventionen zur Ressourcennutzung einigen, damit die verschiedenen Komponenten die Prozessorleistung effektiv nutzen können. In den letzten Jahren sind Programmiermodelle wie das Open Multi Processing (OpenMP), die Open Compute Language (OpenCL) und das Multicore Application Programming Interface (MCAPI) entstanden. Diese empfehlen sich immer dann, wenn ein kohärentes Multicore-Programmiermodell benötigt wird. Abgesehen von diesen Programmiermodellen haben einige höhere Betriebssysteme wie Linux und OSE das Konzept der Multicore/Multiprozessor-Programmierung aufgegriffen, wofür gut ausgearbeitete APIs (Application Programming Interfaces) wie zum Beispiel �??pthreads‘ benutzt werden.OpenMP eignet sich am besten, wenn ein Applikations-Design unterteilt werden kann - nämlich in einen Master-Thread und mehrere parallele Arbeits-Threads, die vom Master-Thread angestoßen werden und unabhängig auf mehreren Cores laufen. OpenMP 3.0 definiert ein bestimmtes Sprachkonstrukt, mit dem Programmierer Anfang und Ende der Parallelverarbeitung definieren können. Darüber hinaus können die Programmierer auch jene logischen Punkte angeben, an denen sich verschiedene Arbeits-Threads synchronisieren lassen. OpenCL ist vorwiegend für jene Fälle geeignet, in denen die Applikation einen Master-Thread enthält und es notwendig ist, das Arbeitsaufkommen in weitgehend parallel laufenden Instanzen, den so genannten Work Kernels, zu berechnen. Ein typisches Beispiel hierfür ist eine Applikation, in der auf einem Universal-Prozessor ein Master-Thread läuft, der über schnelle Verbindungen mit Multicore-Prozessoren oder Grafikeinheiten kommuniziert. �?hnlich wie OpenMP definiert auch OpenCL ein spezifisches Sprachkonstrukt, mit dem Programmierer bestimmte Rechenbereiche sowie Programmierschnittstellen zum Ausführen der Berechnungen angeben können.MCAPI bietet eine weitere Option für die Multicore-Programmierung durch sorgfältig definierte Schnittstellen. Mit MCAPI lässt sich ein Entwicklungsprozess bezogen auf die Entwicklung von MCAPI-Knoten definieren. Die MCAPI-Knoten können dynamisch zur Laufzeit aktiviert und über MCAPI-Kommunikationskanäle miteinander verbunden werden. Daten- und Verarbeitungsablauf können von den Programmierern entsprechend den Anforderungen der Applikation konstruiert werden. Applikationsentwickler müssen sich für das bestmögliche Programmiermodell entscheiden, das für ihre Anwendung am effizientesten ist. In einigen Fällen ist die Wahl des Programmiermodells eng an die Prozessorarchitektur gebunden, da sich einige Multicore-Architekturen besser für ein bestimmtes Programmiermodell eignen. Zum Beispiel passt OpenMP sehr gut zu der Architektur mit Shared-Memory-Unterstützung. Die Verwendung eines standardisierten, offenen Programmiermodells hat viele Vorteile:
Es besteht die Auswahlmöglichkeit unter verschiedenen konformen Softwareblöcken. Einfache Migration von einer Prozessorarchitektur auf eine andere, die dasselbe Programmiermodell unterstützt. Die Festlegung einheitlicher Entwicklungs-Richtlinien für mehrere Entwicklungs-Teams vereinfacht den Entwicklungsprozess.Die zusammen mit einem Entwicklungs-Kit für Multicore-Software zur Verfügung gestellten Software-Schichten müssen sicherstellen, dass die Applikationen die Kommunikations-Schnittstellen der Multicore-Prozessoren effektiv nutzen können. Standardbasierte Programmiermodelle tragen diesen Anforderungen mittlerweile Rechnung. OpenCL gibt per Definition keine physische Schnittstelle vor, sondern überlässt dem Host/Master-Prozessor die Verteilung der verschiedenen Kernels für die Berechnungen. Sofern der passende Umfang an Verarbeitungs- und Ausführungs-Ressourcen vorhanden ist, kann ein Master/Host mehrere verschiedene Multicore-Chips als Beschleuniger nutzen.
Debugging
Multicore-Bausteine bringen ganz spezifische Debug- und Performance-Probleme mit sich. Beispiele sind Ressourcenkonflikte und Synchronisationsprobleme, die bei Single-Core-Systemen nur äußerst selten vorkommen. Grundsätzlich setzen Multicore-Bausteine die gleichen elementaren Debug-Funktionen voraus, wie sie auch bei Single-Core-Systemen verwendet wurden - darunter die Möglichkeit, den Core zu starten, anzuhalten und in den Einzelschritt-Betrieb zu versetzen. In einem Multicore-System aber ist die Fähigkeit zum synchronen Laden, Starten und Single-Stepping aller Cores äußerst nützlich. Multicore-Systeme können überdies in mehrere Stromversorgungs-Bereiche unterteilt sein, was die Möglichkeit schafft, ganze Subsysteme mit Cores und Peripherie abzuschalten. Das Debug-System muss diese Umschaltungen des Stromversorgungs-Status verkraften und dem Anwender sogar die Möglichkeit geben, diese Zustandswechsel vom Debugger aus zu veranlassen, damit sich die mit der Stromversorgung zusammenhängenden Features einfacher testen lassen.Je ausgefeilter die Verarbeitungsabläufe eines Multicore-Systems werden, umso mehr gewinnen Probleme wie etwa die Synchronisation zwischen den verschiedenen Software-Threads an Brisanz. Standards wie OpenMP und OpenCL ermöglichen die Verarbeitung dieser Software-Threads auf ähnlichen oder auch unterschiedlichen Core-Typen. Die gemeinsame Ressourcennutzung dieser Threads kann zu Race Conditions und Performance-Beeinträchtigungen führen. Ein Debug-Subsystem mit der Fähigkeit, eine zeitlich korrelierte Ansicht der Softwareoperationen auf den verschiedenen Cores zu liefern, kann von unschätzbarem Wert für die Auflösung von Synchronisationsproblemen und Ressourcenkonflikten sein.Multicore-Systeme weisen in aller Regel eine in mehrere Schichten gegliederte Speicherarchitektur auf, was für das Debugging und die Optimierung ebenfalls spezielle Herausforderungen mit sich bringt. Zur Optimierung der mehrschichtigen Speicherarchitektur muss das Debug-System dem Entwickler die erforderlichen Informationen für die optimale Platzierung von Programmen und Daten zur Verfügung stellen. Die Zeit, die ein Entwickler zum Optimieren der Speicheroperationen braucht, lässt sich reduzieren, wenn beispielsweise angegeben ist, in genau welcher Zeile ein Cache-Zugriff fehlgeschlagen ist und das Speicher-Subsystem zum Zugriff auf den externen Speicher zwang. Für das System insgesamt sollte das Debug-Subsystem in der Lage sein, Performance-Informationen zu einem gemeinsam genutzten Speicher oder Interface bereitzustellen.
Deployment
Die abschließende Herausforderung für die Entwickler besteht in den Aufgaben, die sich nach dem Deployment des Produkts ergeben. Es ist in jedem Fall ratsam, eine Überwachungsmöglichkeit für das bereits im Einsatz befindliche Produkt zu schaffen, um auftretende Probleme analysieren zu können. Bei Multicore-Prozessoren kommt es auf die Fähigkeit an, Traces aufzuzeichnen, ohne die reguläre Funktion des Produkts zu stören. Gelegentlich kann es zum Verstehen von Problemen überaus sinnvoll sein, Software mit speziellen Instrumentierungen in das Produkt zu laden. Bei einigen Halbleiter-Plattformen gibt es spezielle Funktionsabschnitte wie etwa System Trace Monitors, die dem Kunden zusammen mit einem Softwareentwicklungs-Kit die Entwicklung deploymentfähiger Software ermöglichen. Inzwischen kommen in den meisten Anwendungen immer mehr Multicore-Prozessoren zum Einsatz. Für die Softwareentwickler ist es deshalb wichtig, über die Probleme Bescheid zu wissen, die mit dem Design, der Entwicklung, dem Debugging und dem Deployment von Software auf Multicore-Bausteineneinhergehen.
