Intel ISTEP 2011 Software Conference (Teil II)

[Marc++us]

Intel ISTEP Software Conference: Dubrovnik, 12. April 2011

Auch in diesem Jahr veranstaltete Intel seine Software Conference zur Vorstellung der aktuellen Entwicklungstools und –tendenzen auf den Intel-Prozessoren. 70 Teilnehmer (Reseller, einige Fachzeitschriften und technische Blogger) trafen dabei auf ungefähr 10 Intel-Spezialisten. In diesem Artikel fasse ich einige der Vorträge ( http://www.softwareproductconference.com/Dubrovnik_press.aspx?page=agenda1 ) zusammen.

Code-Tuning „the Intel way“

In einer Demo zeigte Heinz Bast von Intel, wie man in einem rechenintensiven Programm durch schrittweise Ergänzung mit Intel-Werkzeugen die Anzahl der pro Iteration benötigten Zyklen von 2000 auf etwa 200 reduziert. Das folgende Bild zeigt dabei die Ablaufkette, wie sich Intel das entsprechende Tuning vorstellt:

Der Ablauf zeigt sehr gut auch Intels Philosophie der Parallelprogrammierung: Intel-Compiler, Intel-Analyse-Tool, Intel-Bibliotheken – in dieser Reihenfolge soll der Softwareentwickler das Potential eines Multicore-Systems erschließen.
Zunächst wird also das Programm mit dem Intel-Compiler übersetzt, um den ersten Optimierungsschritt zu beginnen. Damit sollen bereits die ersten Performance-Gewinne erzielt werden, ohne daß man am Code etwas ändert. Danach werden Programmteile mittels Cilk Plus oder OpenMP parallelisiert, was bei Berechnungen und Initialisierungen zu Gewinnen führt – lange Arrays und Vektoren lassen sich parallel schneller füllen.

Analysen mit dem Intel Inspector XE zeigen auf, wo durch die Parallelisierung potentielle Deadlocks und Data-Races lauern, um diese durch Code-Änderungen zu beseitigen. Wem dies noch nicht ausreicht, der fügt dann die Intel Math Kernel Library hinzu, in der sich mathematische und statistische Berechnungen befinden.

Bei den Analysetools stellte Levent Akyil den aktuellen VTune Analyzer vor. Bei den Zuhörern sorgte vor allem die neue Funktion der „Frame-Analyse“ für interessierte Mienen. Bei der normalen Hotspot-Analyse ergibt sich eine Aussage, welche Funktionen oder Aufrufketten welche CPU-Zeit verbrauchen. Diese werden dann zur Optimierung vorgeschlagen. Nur in vielen Anwendungen ist dieser Engpaß gar nicht das wesentliche Problem, wenn zum Beispiel framebasierte Anwendungen (ein Spiel oder eine Videoanwendung) zu optimieren sind.

Denn für die Masse der Frames ist das Programm jeweils rechtzeitig fertig, nur manchmal dauert eine Berechnung länger als die pro Frame zur Verfügung stehende Zeit. Für den Betrachter stellt sich dieses Verhalten als klassischer „Lag“ dar – ein Bild hängt oder ruckelt kurz.
Im folgenden Bild ist eine solche Auswertung dargestellt, man kann für jeden Frame die Laufzeit und deren Verteilung über die Funktionen erkennen. Die Engine von „Total War“ war eines der ersten Produkte, das zusammen mit Intel diesbezüglich auf Parallisierung optimiert wurde. Dazu war eine Entflechtung der bisher eher sequentiell organisierten und oftmals aufeinander wartenden Engine notwendig - es gibt nun nach der Umstellung viele kleine Minitasks für feste Aufgaben, und deren (möglichst) parallele Bearbeitung wird mittels von TBB verwalteten Thread-Pools organisiert.

Die Analyse beschränkt sich damit nicht mehr nur auf den reinen Code, sondern wird damit auch ein Stück weit situationsabhängig. Interessant auch, daß man als Entwickler selbst Programmabschnitte als Beginn und Ende von Frames definieren kann, womit sich völlig neue Optimierungspotentiale ergeben, dargestellt im folgenden Bild.

Embedded heißt heute auch Tablet

In zwei weiteren Vorträgen stellte Thomas Zipplies die Intel-Werkzeuge für die Intel-Plattformen im Embedded-Umfeld vor, meistens in Gestalt eines Atom-Prozessors. Allerdings sind in diesem Umfeld die Anwendungsfelder Cross-Entwicklung (die Software wird nicht auf dem Zielsystem entwickelt, sondern auf einem anderen System) und Remote-Debugging (das Debugging wird von einem zweiten Rechner ferngesteuert, über eine TCP/IP-Verbindung oder ein spezielles JTAG-Interface) wesentlich häufiger anzutreffen. Nur selten sitzt der Entwickler bei diesen Systemen „vor“ seinem System, meistens sitzt er „daneben“.

Interessant sind auch die vorgestellten Möglichkeiten der Remote-Analyse – durch zusätzlichen Code auf dem Zielsystem können Informationen über den Ablauf gesammelt und wieder zurück auf das Entwicklungssystem übertragen werden. Danach können genau wie bei den „normalen“ Analysetools Auswertungen in Bezug auf Optimierungsmöglichkeiten, überflüssige Wartezeiten oder Fehlverhalten des Codes gefahren werden.

Der im folgenden Bild dargestellte Code läuft auf einem über JTAG-Interface verbundenen Embedded-Linux-System, und lässt sich vom Entwicklungssystem aus tracen und verfolgen.

Eine Frage war von besonderem Interesse: was ist jetzt mit MeeGo? Durch die Zusammenarbeit von Nokia mit Microsoft fällt hier ein Partner im Mobiltelefonbereich weg. Intel sieht aber MeeGo nach wie vor als wichtig an, mit dem Einsatzgebiet „Tablet-Markt“, und ganz klar auch als Gegengewicht zu Googles Android.

Erkenntnisse und Schlußworte

Was bezweckt Intel mit seinen Softwaretools? Die Erkenntnis, daß man die aktuellen CPUs nur noch mit Parallelprogrammierung voll ausnutzen kann, ist inzwischen nicht mehr neu. Also bietet Intel eine ziemlich fein abgestimmte Palette von Werkzeugen – zunächst mal mit einem Compiler, der bereits von sich aus so viel parallelisiert wie möglich. Danach kann der Entwickler mit sehr feinen und spezifischen Profiling-Tools seinen Code untersuchen, wo der Code nur sequentiell arbeitet und noch CPU-Zeit verschenkt wird. Der Programmierer schreibt nun den Code um und verwendet nach Möglichkeit dabei Intels Softwarebibliotheken. Dies ist Intels Vorstellung von der Softwareentwicklung auf seinen Prozessoren.

Das größte Problem für Intel dürfte sein die hauseigenen Tools bekannter zu machen. Obwohl inzwischen Firmen wie z.B. Adobe auf den Intel-Compiler umgestiegen sind, und Intels Compiler für Windows, Linux und Mac vorliegen, findet man im Feld weiterhin sehr oft Microsofts Visual Compiler oder den gcc vor. Und wer die Intel Compiler nicht nutzt, benutzt vermutlich auch keine Analyse-Tools von Intel. Da liegt sicherlich noch viel Arbeit vor Intel, damit diese Tools nicht nur in einigen Highend-Anwendungen, sondern auch in Unis und kleinen Firmen benutzt werden.