Die Parallelisierung von bisher seriell ablaufenden Programmen ist eines, aber nicht das einzige Problem, vor dem Software-Entwickler stehen, wenn sie ihre Anwendungen auf eine Multi-Core-Architektur portieren. Denn Multi-Core ist nicht gleich Multi-Core. Beim Parallelisieren gibt es zunächst das symmetrische Multiprocessing (SMP), bei dem die Rechenlast möglichst gleichmäßig auf die vorhandenen Cores verteilt wird. Intel propagiert diese Methode für seine Tools und schärft den Entwicklern ein, sich bei der Entwicklung auf keinen Fall auf eine bestimmte Hardware-Architektur bzw. Anzahl von Cores festzulegen – das macht die Laufzeitumgebung.

Bei Embedded-Geräten wird dieser Verstoß gegen die "reine Lehre" jedoch oft mit voller Absicht praktiziert. Klassisches Beispiel für Dual-Core-Prozessoren ist: Echtzeit-Steuerung auf Core 1, Benutzeroberfläche auf Core 2. Das ist überschaubar und lässt sich händisch gut in den Griff bekommen. Läuft die gleiche Software jedoch auf eine Quad-Core-Prozessor, dann bleiben zwei Cores ungenutzt. Oder ein Redesign der Software ist fällig. Der Quad-Core könnte jetzt noch eine weitere Echtzeit-Aufgabe übernehmen. Oder gar zwei? Reicht dann ein Core noch für die Benutzeroberfläche? Noch schwieriger wird es, wenn ein Hardware-Beschleuniger ins Spiel kommt wie zum Beispiel ein zusätzlicher Grafikprozessor oder ein Video-Codec. Bei der ARM-Architektur ist das Standard: viele unterschiedliche Kerne für spezielle Aufgaben wie Systemverwaltung, Audio- und Video-Verarbeitung, 2D- und 3D-Grafik etc.

Nicht zu viel, nicht zu wenig Prozessorleistung

Für diese Fälle bietet VectorFabrics seine Entwicklungswerkzeuge vfAnalyst und vfEmbedded an. Der schon seit neun Monaten bestehende vfAnalyst ist ein Tool, das den Vorgang der Partitionierung  von Software auf mehrere gleichartige (x86-)Cores unterstützt. Mit vfEmbedded stellt VectorFabrics ein neues Produkt vor, das auch ungleichartige, spezialisierte Cores und Verarbeitungseinheiten modelliert. Die Zielrichtigung von vfEmbedded ist, dass der Entwickler abschätzen kann, der geplante Prozessor genügend Leistung hat, um den Code so abzuarbeiten, dass Zeitschranken eingehalten werden und sich z.B. die Benutzeroberfläche flüssig anfühlt. Andererseits kann der Entwickler an Auslastungsgraphen erkennen, ob die geplante Hardware auch vernünftig ausgenutzt wird – denn Rechenleistung, die überhaupt nicht benötigt wrd, bedeutet unnötige Kosten.

Performance abschätzen, Code zuweisen

vfEmbedded stellt die Auslastung der verschiedenen Cores grafisch dar (unten).

© VectorFabrics

Der Partitionierungsprozess von vfEmbedded identifiziert Codesegmente, die parallel ausgeführt werden können – auf ggf. unterschiedlichen Cores. Im nächsten Schritt, der Zuweisung, entscheidet der Entwickler, welche Code-Teile auf welcher Hardware laufen soll. Auch Hardware-Beschleuniger wie Codecs können hierbei berücksichtigt werden, wenn darüber Informationen für die Modellierung vorliegen. vfEmbedded simuliert die Hardware zwar nicht Befehlssatz-genau, modelliert sie aber ausreichend gut, um eine aussagefähige Performance-Abschätzung zu erhalten.

Prinzipiell sind die vf-Tools nicht auf eine bestimmte Hardware oder Programmiersprache festgelegt. Für die Modellierung müssen jedoch die notwendigen Modelle vorhanden sein. Als solche werden x86 und ARM Cortex-A9 unterstützt. Bei der Programmiersprache kann derzeit C-Code und mit Einschränkungen auch C++-Code eingespeist werden. Die Einschränkungen bei C++ betreffen Libraries, die nicht unterstützt werden. Eine Unterstützung für Fortan für wissenschaftliches Hochleistungsrechnen ist geplant.

Cloud-Anwendung

vfAnalyst und vfEmbedded sind Cloud-Computing-Werkzeuge. Sie laufen derzeit in der Amazon-Cloud und werden in Irland gehostet. Für den Kunden bedeutet dies, dass er sich um die Software-Installation keine Gedanken machen muss. Der Zugriff erfolgt über einen Standard-Webbrowser durch Anmeldung auf der VectorFabrics-Website. Die Nutzungsgebühr beginnt bei 450 Euro pro Monat. Kostenlose Probezugänge mit verschiedenen Design-Beispielen sind möglich.

Joachim Kroll, Elektronik