Im Gegensatz zur früheren Version verfügt das neue Release über Support für Multi Socket-Systeme und die Möglichkeit per API-Layer (diverse Librariers und DLLs) via C/C#/C++ oder JavaScript relevante Energieinformationen auszulesen und weiterzugeben. Sie können das Tool über das Gadget bedienen oder auch über die Kommandozeile steuern. Dafür steht Ihnen die Funktion PwrLogSample.exe zur Verfügung.

Systemvoraussetzungen:

• Windows 7 32-bit oder 64-bit
• Windows Server 2008, Windows Server 2008 RC2 (64-Bit Server)
• Microsoft .Net Framework 4
• Microsoft Visual C++ 2010 SP1 (x86 oder x64 anhängig vom OS)
• Sandy Bridge-Prozessor

• Intel GPA Frame Analyzer ist ein intuitiv bedienbares Tool zur Analyse und Optimierung einzelner Frames.
• Intel GPA System Analyzer Heads-up Display (HUD) bietet eine erste und grundlegende (Fehler-)Analyse, ermittelt Bottlenecks und misst die Grafik-Performance auch hinsichtlich möglicher Microsoft 3D-Effekte
• Intel GPA Platform Analyzer stellt eine Zeitskalenansicht für die Analyse von Tasks, Threads, Microsoft DirectX, OpenCL und anderen GPU relevaten Applikationen zur Verfügung.

Wenn Sie mehr darüber erfahren möchten, empfehle ich Ihnen diesen Beitrag von der GDC Europe 2011 zum Thema GPA.

Nun zu den Neuerungen der Version 4.2. Gegenüber der Version 4.1 vom Anfang des Jahres kamen abgesehen von einigen Fixes folgende Funktionen hinzu:

• Aktualisierte Intel Instrumentation und Tracing Technology (Intel ITT): Mehr Tracing-Informationen werden gesammelt, um typische Problemfelder wie Flaschenhälse noch exakter zu ermitteln
• Die Task Timeline Ansicht stellt nun auch Task Sub-States dar
• Task-Daten können nun auch über die OS- Scheduler Informationen hinaus abgerufen werden
• Task-Farben können nun flexibler angepasst werden um die Übersichtlichkeit der Darstellung zu verbessern
• In der Zeitskalenansicht kann der Anwender nun eigene Tracks hinzufügen

Neugierig geworden? Dann probieren Sie GPA doch selbst in Ihrem persönlichen Umfeld aus. Als Mitglied des Intel Visual Adrenaline Developer Programms können Sie die Tool-Sammlung kostenlos downloaden. Und hier können Sie sich für das Intel Visual Adrenaline Developer Programm registrieren, wenn Sie noch nicht dabei sind.
Andernfalls kostet GPA 4.2 299 US-Dollar und wird hier angeboten.
News-Beiträge, Workshops, Tutorials und Videos zu dem cleveren Toolset können Sie übrigens regelmäßig hier abrufen.

Solch ein Flow Graph besteht aus drei Elementen: das Graph-Objekt, Knoten und Verbindungen. Das Objekt stellt Methoden zur Verfügung, mit deren Hilfe Tasks ausgeführt und beendet werden können. Die Knoten hingegen erstellen, transformieren und speichern Nachrichten. Und die Verbindungen machen aus dem Graph eine Einheit, indem sie die Knoten miteinander verbinden und auf diesem Weg die Nachrichten von Knoten zu Knoten senden. Es gibt diverse Typen von Knoten, die sich je nach Aufgabe einsetzen lassen:

Funktionen: Hierfür sind vier Typen vorgesehen: source_node, continue_node, function_node und multioutput_function_node.

Speichern (Buffering): Hierbei wird unterschieden in buffer_node, queue_node, priority_queue_node und sequencer_node.

Teilen/Vereinen (split/join): Die zugehörigen Knoten lauten queueing_join, reserving_join, tag_matiching_join, split_node und nor_node.

Diverse: Darunter fallen broadcast_node, write_once_node, overwrite_node und limiter_node.

Und so sieht das Ganze in der Symbolansicht aus:

Diese Knoten werden von Intel TBB Flow Graph unterstützt

Im folgenden Bild ist ein möglicher Einsatz des Intel TBB Flow Graph zu sehen. Dabei soll der Verlauf einer Wellenfront mit Hilfe einer Reihe von Continue-Knoten dargestellt werden. In diesem Beispiel kann eine Berechnung erst dann ausgeführt werden, sobald die Berechnungen oberhalb und links von ihr abgeschlossen sind. Ist dies geschehen, erhält der jeweilige Knoten eine Nachricht vom Typ contiune_msg.

Mit Hilfe dieses Beispiels soll der Verlauf einer Wellenfront berechnet werden

Ein komplettes Beispiel solch einer Flow-Graph-Implementierung zeigt der zugehörige Blogbeitrag von Michael Voss.

Der Quellcode-Editior wurde um neue Funktionen für das Projektmanagement erweitert. Das bedeutet unter anderem, dass MSBuild-Projektdateien mit Visual Studio durch das Update kompatibler und darüber hinaus angepasste Frameworks unterstützt werden. Auch neu: die Syntax lässt sich farblich individuell darstellen, indem man eigene Farbschemen festlegt und diese je nach Projekt einsetzt.

Mac-Entwickler können ab sofort Xcode 4 für das Schreiben ihres Quellencodes einsetzen. Somit können beispielsweise Interface-Builder-Dateien mithilfe von Xcode 4 editiert werden. Desweiteren sollen neue MonoTouch-Beispiele dabei helfen, Xcode 4 besser einzusetzen.

Außerdem wird der Testing-Services TestFlight unterstützt. Hierfür müssen Sie sich lediglich auf testflightapp.com anmelden, das zugehörige SDK in Ihre Build-Datei integrieren, dieselbe hochladen, testen lassen, fertig. Darüber hinaus lassen sich die Pfade zum Portierungstool MonoTouch und zum iOS SDK besser konfigurieren, es gibt neue Projektvorlagen für iPhone und iPad und die neue Storyboard-Funktion, die unter iOS 5 zur Verfügung steht, wird ebenfalls unterstützt.

MonoDevelop 2.8 können Sie von der Download-Seite auf Ihren Rechner laden. Unterstützt werden Windows, Mac OS X sowie die Linux-Distributionen openSUSE, SLE, Debian und Ubuntu.

Eine wichtige Verbesserung bzw. Neuheit stellt der Flow Graph dar, den man ja schon im fünften Update der Intel TBB 3.0 vorgefunden hat, allerdings noch nicht in der finalen Version. Dies ist mit Intel TBB 4.0 geschehen, und Software-Entwickler werden diese neue Funktion lieben.

Denn mit dem Flow Graph lassen sich Abhängigkeiten zwischen einzelnen Berechnungen und Algorithmen grafisch darstellen. Das betrifft sowohl statische als auch dynamische Operationen. Dies ist vor allem bei der Visualisierung von parallelisierten Codeabschnitten sehr hilfreich, da vor allem in diesen speziellen Fällen unvorhersehbare Nebeneffekte auftreten können, die mit Flow Graph unter Umständen sichtbar werden.

Neben Flow Graph spielen neue Mechanismen in TBB 4.0 ein weitere wesentliche Rolle, mit deren Hilfe Speicheroperationen auf definierte Bereiche beschränkt werden können. Diese Memory Pools eignen sich ebenfalls dazu, mögliche Speicherprobleme bei parallel programmierten Codeabschnitten zu vermeiden.

Für die explizite Parallelprogrammierung kommt in Intel TBB 4.0 eine Concurrent Memory Queue zum Einsatz, mit deren Hilfe die Abarbeitung paralleler Aufgaben einfacher gewichtet, also priorisiert werden können. Und mit  den neu eingeführten Concurrent Unordered Sets können Software-Entwickler thread-sichere Container zum Ablegen von Nutzerobjekte erstellen und per Hashkey nutzen.

Darüber hinaus lassen sich auch Tasks und ganze Task-Gruppen priorisieren, und zwar auf drei verschiedenen Ebenen, nämlich Low, Normal und High. Last but not least unterstützt der GCC dank Intel TBB 4.0 ab sofort thread-sichere atomare Operationen, was Parallelcode noch effizienter machen soll.

Intel Threading Building Blocks 4.0 gibt es in Varianten für Windows, Linux und Mac OS X, und zwar kostenfrei, wenn man damit nicht-kommerzuielle Projekte betreibt (auf Basis der GPLv2 mit Runtime Exception). Für kommerzielle Projekte stehen diverse Kaufversionen von Intel bereit. Und das inklusive Support.

Heute gibt es wichtige Neuigkeiten für Fortran-Programmierer, denn Intel bietet ab sofort eine angepasste Version der Entwickler-Suite Parallel Studio XE 2011 an, die sich Fortran Studio XE 2011 nennt und sämtliche Komponenten bietet, die man auch von Parallel Studio XE 2011 kennt. Dazu gehört der Fortran-Composer, den es für Windows, Mac OS X und Linux gibt. In diesem Paket befinden sich neben dem Fortran-Compiler Multicore-optimierte Bibliotheken, spezielle Vektor-Funktionen und die Intel Parallel Building Blocks, die Thread-sichere Funktionen zur Verfügung stellen.

Darüber hinaus gehört zu Fortran Studio XE 2011 auch das Analyse-Tool VTune Amplifier XE und das Speicher-Überprüfungs-Werkzeug Inspector XE, das Intel für Fortran-Zwecke angepasst hat, da es ja bisher nur C- und C++-Entwicklern zur Verfügung stand.

Damit entspricht Fortran Studio XE 2011 funktionsseitig vollständig Parallel Studio XE 2011, allerdings mit angepassten und aktualisierten Komponenten. Dazu gehört das Update 12.1.0 des Fortran-Compilers, dem Intel eine Reihe an Verbesserungen spendiert hat. Dazu gehören folgende Funktionen:

• ALLOCATE auf Basis eines polymorphen SOURCE= wird jetzt unterstützt
• zahlreiche neue Visual-Studio-2010-Funktionen wie der Code-Browser (aber nur für Visual Studio 2010)
• OpenMP 3.1 wird jetzt unterstützt
• die Intel Math Kernel Library wurde auf 10.3 Update 6 aktualisiert

Weitere Infos zu Fortran Studio XE 2011 bekommen Sie in dem zugehörigen Blogbeitrag, in dem Steve Lionel von Intel ausführlich auf die Entwickler-Suite eingeht.

Im Interview erklärt er, wer GPA unbedingt braucht, welche Verbesserungen die Version 4.1 gegenüber dem Vorgänger verspricht und wie Sie sehr, sehr günstig an die aktuelle Version kommen, um die Grafikleistung auch Ihrer eigenen Spiele zu optimieren.

Hier das sehr sehenswerte Video dazu:

Später werde ich von noch von seiner Session berichten.

Wie schafft es Ateji, die Parallelprogrammierung einfacher zu machen?

Nun, zunächst haben wir eine bestehende Sprache erweitert (nämlich Java), sodass es nicht notwendig ist, eine neue Sprache zu lernen (weitere sollen folgen). Dann haben wir auf Basis einer mathematischen Formel eine parallele Extension entwickelt, mit deren Hilfe sich parallele Ausdrücke mit einem einfachen Operator kombinieren lassen. Wenn Sie beispielsweise eine Funktion a und b parallel ablaufen lassen wollen, müssen Sie das lediglich als a || b in Ihren Quellcode einfügen.

Welche Programmiermodelle unterstützen Sie?

Dazu gehören eine ganze Menge:

• task-basierte Modelle wie Cilk
• daten-basierte Modelle wie OpenMP
• rekursive und spekulative parallele Konstrukte
• und einiges mehr.

Worin unterscheiden sich die Ateji-Extensions von anderen Erweiterungen, die es zum Zwecke der Parallelprogrammierung bereits gibt? 

Nun, da gibt es eine Reihe von Unterschieden:

• Chapel, X10, Fortress, etc. adressieren den Bereich des High Performance Computing (HPC), sind also vor allem für Supercomputer ausgelegt. Ateji PX wurde für “einfache” Java-Entwickler geschrieben, die Anwendungen für herkömmliche Multicore-Server und -Cluster schreiben.
  
• Es handelt sich dabei im eine Spracherweiterung, die mit Standard-Java-Code kompatibel ist.
  
• Der einfach zu erlernende ||-Operand erlaubt es, diverse Parallelisierungs-Konstrukte mithilfe einer einzigen Sprache auszudrücken.
  
• Unsere Extension basiert auf einer erprobten, zuverlässigen mathematischen Formel, sodass wir genau vorhersagen können, was innerhalb des parallelen Konstrukts passieren wird. Das bedeutet auch, dass der Compiler mögliche Fehler wie Data Races relativ genau vorhersagen kann.

Wie reagieren Entwickler auf Ihre Java-Extension?

Nun, unsere Hauptaussage, dass mit Ateji PX die Parallelprogrammierung einfacher wird, ließ sich schon des öfteren bestätigen. So können Entwickler in der Regel innerhalb eines halben Tages ihr erstes parallel programmiertes Programm schreiben und zum Laufen bringen. Und ein großes Bankinstitut hat es tatsächlich geschafft, innerhalb von zwei Tagen ihre Java-Anwendung derart zu parallelisieren, dass sie hinterher fünf mal schneller lief als ohne den Parallelisierungsaufwand.

Weitere Informationen zur Ateji PX Extension für Java gibt es im zu zugehörigen PDF oder auf der Ateji PX Webseite. Es gibt auch eine Case Study, die zeigt, wie sich mit Hilfe von Ateji eine Server-Anwendung mit 16 Prozessorkernen um den Faktor 12,5 beschleunigen ließ.

Nun, zunächst einmal stelle man sich vor, dass man eine seriell/sequentiell programmierte Anwendung gebaut hat, von der man gerne wissen möchte, ob sie auf einem Multicore-System schneller laufen würde, wenn sie parallel programmiert wäre. Und das betrifft schließlich einen Großteil sämtlicher Computersysteme, die derzeit am Markt zu kaufen sind. Denn das Parallelisieren von Software-Anwendungen kostet Zeit und Geld und sollte damit wohl überlegt sein.

Und genau hier setzt Parkour an. Anhand einer hirarchischen Analyse sämtlicher kritischen Pfade einer Anwendung (Hierarchical Critical Path Analysis) ermittelt das Tool diejenigen Codebereiche, die sich ganz besonders für die Parallelisierung von seriellem Code eignen. Hierzu gehören vor allem Schleifen und Rekursionen, aber auch andere Konstrukte. Für diese Analyse muss allerdings keine Instrumentalisierung (Instrumantation) des Codes vorgenommen werden, da dies der Parkour-Compiler übernimmt. Das Ergebnis der vollständigen Anaylse einer Anwendung mit Hilfe von Parkour stellt eine Vorhersage anhand eines 64-Core-Systems dar. Damit lässt sich relativ genau prognostizieren, in welchem Ausmaß die serielle Anwendung im parallelisierten Fall skalieren würde, und zwar auf 1, 2, 4, 8, 16, 32 und 64 Prozessorkernen.

Die Grenzen von Parkour werden allerdings bei kurzem Nachdenken recht schnell klar: Neben der hilfreichen Aussage, in welchem Umfang die Anwendung auf x Kernen laufen würde, fehlen nützliche Hinweise, in welchen Bereichen die Parallelisierung des Software-Programms sinnvoll wäre. Hierfür benötig man also andere Tools, so wie Intel Parallel Advisor oder CilkView, wobei CilkView ähnlich wie Parkour arbeitet. Parallel Advisor hingegen gibt Auskunft darüber, an welchen Stellen Optimierungspotenzial besteht und wie dies zu implementieren ist. Allerdings steht Parallel Advisor nur C/C++-Entwickler zur Verfügung. Mehr Infos hierzu finden Sie auch bei Intel.

Ach ja: Die Herren Amdahl und Gustafson haben sich schon vor vielen Jahren zur Skalierbeit von Software-Anwendungen so ihre Gedanken gemacht.

Die auf der zugehörigen Webseite verfügbaren Beispiele zeigen recht eindrucksvoll, wie das Ganze aussehen kann. OK, Tetris ist nicht so der Brüller, aber das Indiana Jones-Verschnitt-Spiel kann sich durchaus sehen und spielen lassen. Das Spiel läuft recht flüssig, je nach vorhandener Hardware. Und bei der Wahl des Browsers sollte man ebenfalls wählerisch sein: So werden nur die aktuellen Webbrowswer wie Internet Explorer 9, Firefox 4, Safari 5 und Chrome 11 vernünftig unterstützt, da diese den noch recht neuen JavaScript-Standard ECMAScript 5 sowie HTML5 beherrschen. Alle Opera-Anwender werden sich daher noch ein wenig gedulden müssen.

Es sind lediglich vier Schritte notwendig, um JSIL für seine eigenen Zwecke einzusetzen:

1. Erstellen Sie mithilfe von Git eine Kopie des zugehörigen Repositories (vergessen Sie die Submodule nicht).
2. Erzeugen Sie mithilfe von Visual Studio 2010 (ja, die Express-Version funktioniert auch) die Build-Datei JSIL.sln.
3. Lassen Sie die so erzeugten JSILc.exe über Ihre .NET-Anwendungen laufen.
4. Versuchen Sie, die entstandenen Fehler zu korrigieren (JSIL befindet sich noch im Beta-Stadium).

Ach ja: JSIL ist nicht der erste Versuch, .NET in Java- oder JavaScript-basierten Code umzuwandeln. Die Projekte IKMV.NET und XMLVM haben dies bereits vorgemacht. Vor allem das XMLVM-Projekt ist für Entwickler mobiler Anwendungen äußerst interessant, da sich auf diesem Weg Android-Apps in iPhone- und iPad-kompatible Anwendungen konvertieren lassen. Hierfür bietet XMLVM die Möglichkeit, Java Bytecode in Objective-C-Code umzuwandeln.

Und was hat das mit dem Thema GPCPU zu tun? Nun, wie Intel ja schon vor längerem angekündigt hat, wird das ehemalige Vorzeigeprojekt Larrabee wieder auferstehen, und zwar unter dem Namen Knights Corner. Dabei handelt es sich um eine Art Co-Prozessor, der 50 Prozessorkerne umfassen, in der 22-Nanometer-Technik gebaut und für parallele Rechenaufgaben geradezu prädestiniert sein wird. Das Ganze wird im Laufe des nächsten Jahres auf den Markt kommen.

Und genau hier setzt OpenCL ein, denn mit diesem Framework, das mit OpenCL C konform ist und diverse Tools für Programmierer bietet, lassen sich vor allem grafisch-orientierte Aufgaben deutlich schneller ausführen als auf jedem Standard-PC, der CPU und GPU nicht gemeinsam nutzen kann.

Das Intel OpenCL SDK 1.1 Beta umfasst folgende Merkmale:

• Das SDK ist vollständig kompatibel mit der OpenCL-Spezifikation
• Beta-Support für Microsoft Windows (32 and 64 bit)
• Alpha-Support für Linux
• OpenCL-Client-Treiber
• CPU-Vektorisierungsmodule für SIMD-Berechnungen

Darüber hinaus werden folgende optionale Core-Features unterstützt:

• Out-of-Order-Execution
• Unterstützung nativer Kernels
• native Verarbeitung von Bildern
• Code-Optimierungen mithilfe bestimmer Compiler-Einstellungen (cl-fast-relaxed-math)
• Floating Point-Erweiterungen für Berechnungen mit doppelter Genauigkeit (cl_khr_fp64)
• Code-Beispiele
• Debug- und Analyse-Tools sind ebenfalls Teil des SDKs (z.B. Intel GPA und VTune Amplifier-Support)

Mithilfe des zugehörigen Links kann das Intel OpenCL SDK auf den eigenen PC zu Testzwecken geladen werden.

Dabei handelt es sich um ein Performance Analyse-Tool für unterschiedliche Systemplattformen wie Windows und Linux. Neben den gewohnten Power-Funktionen etwa zur Identifizierung von Flaschenhälsen und Leistungsbremsen im Sourcecode, hat Intel eine Reihe von Verbesserungen zur Datenkontrolle, Analyse und Visualisierung integriert.

Die wichtigsten Funktionen und Eigenschaften des Performance Tuning Utility:

• Ereignisbasiertes Sampling: Über die prozessoreigene Leistungsmessung lassen sich Probleme sehr genau ermitteln

• Block-Analyse: Hotspots werden exakt ermittelt

• Visualisierung: Performance-Histogramme stellen Leistungshöchst- und Tiefstwerte in der Anwendung dar

• Schleifen-Analyse: Ermitteln von Loops und Rekursionen im Code

• Data Access Profiling: Identifizieren von Memory-Hotspots und Zuordnen zu Code-Hotspots

• Heap Profiler: Ermitteln der Speichernutzung der Anwendung und in der Folge auch von möglichen Memory-Leaks

Insgesamt gesehen bietet die Toolbox hinsichtlich Performance-Analyse ähnliche Funktionen wie der Intel VTune Performance Analyzer. Allerdings profitieren vor allem erfahrene Anwender von den sehr flexiblen Profi-Features.

Dazu gehört ab sofort eine detailliertere Speicherdiagnostik hinsichtlich der CPU-Nutzung. Leistungsprobleme können so schneller dem Sourcecode zugewiesen werden, um Korrekturen einzuleiten. Auch die grafische Darstellung von Leistungswerten -und kurven wurde erweitert.

Hier eine Übersicht der Neuerungen:

• volle Unterstützung für Sandy Bridge inklusive AVX

• bessere Unterstützung für neue Atom-Prozessoren von Intel

• neue Profile ermöglichen bessere Konfiguration

• verbesserte Hotspot-Analyse

• Möglichkeit zur Integration des Intel Performance Bottleneck Analyzer

• diverse Fehlerkorrekturen

Neugierig geworden? Hier gibt es den Download und eine detaillierte Übersicht zu allen Neuerungen.

Beginnen wir mit den Updates:

Der Parallel Advisor 2011 wurde mit einem zweiten Update aufgewertet. Zum einen wurden, wie bei Updates üblich, kleine Fehler korrigiert. Zum anderen wurde das Tool aber auch für das Zusammenspiel mit Windows 7 Service Pack 1 und Microsofts Entwicklungsumgebung Visual Studio 2010 optimiert.

Hintergrund: Der Parallel Advisor ist eines der wichtigsten Entwicklerwerkzeuge von Intel, um festzustellen, welche seriellen Codebestandteile Parallelisierungs-Potenzial haben und wie sich entsprechende Threads implementieren lassen.

In diesem Blog habe ich bereits mehrfach über den Parallel Advisor und dessen Möglichkeiten in der Programmierpraxis berichtet.

Auch Intels VTune Amplifier XE hat per Update ein paar neue Funktionen erhalten. Das Tool ist konsequent auf die neue Sandy-Bridge-Generation ausgerichtet und bietet nun neue Performance- und Analyse-Funktionen wie

• vordefinierte Event-Profile zur einfacheren Diagnose

• mehr integrierte Messverfahren etwa zur Speicherbelegung

• automatisches Markieren von Code-Elementen, die einen bestimmten Normwert übersteigern

• Tooltipps

Hintergrund: Der VTune Amplifier XE sammelt, analysiert und bewertet Leitungsdaten in vorhandenen Programmen, um Schwachstellen und Flaschenhälse zu ermitteln.

Weitere Informationen zum VTune Amplifier können Sie ebenfalls in diesem Blogbeitrag nachlesen.

Zudem hat das Intel ISN eine Reihe neuer Videos im Rahmen des Parallel Programming Talk veröffentlicht. Der Parallel Programming Talk ist eine wöchentliche Video-Show im Intel Software Network TV, die sich an Parallel-Programmierer wendet – auch an Einsteiger. Um zu neuen Video-Aufzeichnungen auf dem Laufenden zu bleiben, können Sie sich auch per Twitter informieren lassen.

Interessant aus Entwicklersicht ist aber auch eine Technik, die es in der Vorgänger-Architektur “Nehalem” bereits gab und die eine Überarbeitung erfahren hat: Turbo Boost. Mit Turbo Boost 2.0 von Sandy Bridge geht Intel einen Schritt weiter und fokussiert sich im Gegensatz zur Version 1.0 nicht nur auf sequentiell ablaufende Anwendungen, sondern auf seriell und parallel programmierte Apps gleichermaßen. Und mithilfe des Tools Intel Turbo Boost Technology Monitor kann man dem Prozessor-Turbo unter Windows 7 in Echtzeit bei der Arbeit zusehen.

Einer der wesentlichen Unterschiede zwischen TB 1.0 und 2.0 ist die längere Boost-Zeit, die auf die vorhandenen Prozessorkerne verteilt werden kann. Darüber hinaus funktioniert diese Turbo-Funktion hinsichtlich CPU und GPU, die ja seit der Einführung von Sandy Bridge auf einem gemeinsamen Die sitzen (Stichwort: SoC).

Hierfür hat Intel einen ausgeklügelten Algorithmus entwickelt, der stets auf der Suche nach dem perfekten Mix aus Leistungbedarf und aktueller Auslastung sucht. Gleichzeitig wird stets darauf geachtet, dass die Leistungsaufnahme von CPU und CPU möglichst optimal ist, was vor allem bei Notebook-Prozessoren wichtig ist, um so längere Akkulaufzeiten zu erreichen.

Aber zurück zum Turbo-Boost-Tool von Intel. Dieses kleine Werkzeug ist immer dann nützlich, wenn man verstehen will, was gerade beim Ausführen einer Anwendung passiert. Hierfür folgt das Tool einer bestimmten Farbkodierung:

• Ist Turbo Boost nicht aktiv und die CPU verbraucht weniger Strom als spezifiziert, leuchtet ein grünes Blatt und die Bezeichnung “Energy Saver” auf.

• Wenn sich die aktuelle Frequenz unterhalb der spezifizierten Taktrate bewegt, wird ein dunkelblauer, senkrechter Balken angezeigt, aber ohne eine Angabe der aktuellen Frequenz.

• Aktiviertes Turbo Boost 2.0 wird mithilfe eines hellblauen Balkens und der TB-Frequenz dargestellt. Außerdem wird der Text “Intel Turbo Boost Technology 2.0″ angezeigt.

Beim Installieren des TB-Tools sollte beachtet werden, dass nur Windows 7 sowie sämtliche Intel-Core-Prozessoren der zweiten Generation (“Sandy Bridge”) richtig unterstützt werden.

Tipp: Jenseits des Intel-TB-Tools gibt es ein ähnliches Werkzeug, das sich TMonitor nennt und vom CPUID-Team stammt. Damit lassen sich einerseits auch ältere Prozesorren beobachten, und andererseits werden die aktullen Taktraten aller Prozessorkerne angezeigt.

Intel hat dazu eine interessante Beispielanwendung veröffentlicht, die es Spiele-Entwicklern ermöglichen soll, unterschiedliche Shadow-Algorithmen hinsichtlich Qualität und Performance zu vergleichen. Auf zwei unterschiedliche Szenen werden die Algorithmen angewendet: Ein „Stadtbild“ als typisches Game-Setting mit unterschiedlichen Sonneneinstrahlungen und Schattendimensionen sowie ein kugelförmiges „Gitterobjekt“ mit diffizilen Schattenelementen.

Die Beispielanwendung basiert auf dem neuen Shadow Explorer. In der ersten Version bietet der Shadow Explorer vier Algorithmen, die sich hinsichtlich der Komplexität unterscheiden:

• Simple shadow maps
• Percentage closer shadow maps
• Variance shadow maps
• Exponential variance shadow maps

Ganz gleich, für welche Methode sich der Entwickler entscheidet, er hat über den Shadow Explorer Zugriff auf unterschiedliche Variablen und Filter, die ihm die Möglichkeit geben, die Schatteneffekte zu variieren und die jeweilige Technik in Echtzeit auszuprobieren, zu verfeinern und später auf den eigenen Quellcode zu übertragen. Kurzum: Der Shadow Explorer hilft, viel Zeit beim Experimentieren mit 3D-Effekten zu sparen.

Wie üblich hat Intel dazu auch ein schickes Video veröffentlicht

Das kann man einerseits selbst erledigen, indem man zunächst bestimmte Konstrukte parallelsiert, um den Multicore-Koeffizienten zu verbessern. Hierzu eignen sich ja beispielsweise Schleifenkonstrukte, die eine große Zahl an Daten in kurzer Zeit manipulieren. Sobald man testweise eine for-Schleife mit dem richtigen Befehl und dem dazu passenden Programmiermodell (wie zum Beispiel OpenMP) parallelisiert hat, kompiliert man die Anwendung erneut, startet den Concurrency Checker und betrachtet die so ermittelten Testergebnisse.

Das ist natürlich aufwändig und erfordert ein gewisses Maß an Paralleliserungs-Know-now. Einfacher geht es da mit dem zugehörigen Service, den Intel Software-Entwicklern kostenlos anbietet. Das einzige, was Sie hierfür benötigen, ist ein gültiger Account des Intel Software Partner Program. Sobald Sie Besitzer der notwendigen Login-Daten sind, können Sie den Testbericht, den der Concurrency Checker automatisch ausspuckt, auf den Intel-Server laden. Dieser wertet die Daten aus und stellt diese in grafischer Art und Weise am Bildschirm dar.

Falls die hierfür eingesetzten Tools Parallelisierungspotenzial innerhalb Ihrer Anwendung finden, bekommen Sie das mitgeteilt und Sie müssen sich selbst um das Aufspüren der möglichen Sourcecode-Stellen nicht kümmern. Was Sie allerdings schon wissen sollten, wie Sie die identifizierten Stellen mit entsprechenden Parallel-Konstrukten versehen. Und das wiederum erfordert ein wenig mehr als nur den Concurrency Checker. Aber wozu gibt es dieses Blog, oder?!

Falls Sie sich zu dem Thema ein Video angucken wollen, hilft ein Mausklick auf diesen Link. Oder Sie besuchen die Concurrency-Checker-Seite, die Intel speziell zu diesem Thema zusammen gezimmert hat.

Mit Intel Composer XE verhält es sich wie mit einem Schweizer Taschenmesser: Man bekommt für jeden Job das richtige Tool an die Hand. Will man beispielsweise C++-Projekte unter Windows oder Linux oder Mac OS X kompilieren, ist die neue Intel-Entwicklersuite das richtige Tool für Sie. Oder sind Sie eher Fortran-Entwickler und sind auf der Suche nach dem passenden Compiler, egal ob für Windows, Linux oder Mac OS X? Dann ist der Composer XE 2011 ebenfalls eine gute Entscheidung.

Doch nicht nur die plattform-übergreifende Kompilierung macht aus dem Intel Composer XE ein mächtiges Tool. Denn neben der Optimierung für AVX- und SIMD-Befehle zeichnet sich das Entwicklerwerkzeug durch weitere Bausteine aus:

• Intel Parallel Building Blocks (Intel PBB): Eine Toolsammlung, die Intel Threading Building Blocks, Intel Array Building Blocks und Intel Cilk Plus umfasst.
• hoch-optimierte Software-Bibliotheken: Dies sind Intel Math Kernel Library und Intel Integrated Performance Primitives.
• High-Performance Parallel Optimizer: Damit lassen sich vor allem verschachtelte Schleifenkonstrukte besser untersuchen.
• Interprocedural Optimization: hiermit lassen sich vor allem kleinere und mittlere Funktionen parallelisieren, die oft zum Einsatz kommen und in denen Funktionsaufrufe innerhalb von Schleifen vorkommen.
• Profile-Guided Optimization: verbessert die gesamte Laufzeit-Performance, indem unter anderem der Sourcecode neu arrangiert wird, die Code-Größe reduziert wird und fehlerhafte Sprungvorhersagen entfernt werden.

Weitere Infos zu Intel Composer XE 2011 gibt es entweder als PDF, auf der englischsprachigen Webseite oder in Videoform im Intel Learning Lab.

Mit dem Inspector XE 2011 lassen sich in C/C++-Anwendungen, aber auch in C#- und Fortran-Programmen eine Reihe von Fehlern aufspüren, und das, bevor der Fehler überhaupt erst auftaucht. Zudem benötigt man keine aufwändigen Testumgebungen, da das Tool anhand des Sourcecodes mögliche Schwachstellen aufspürt und diese grafisch anschaulich darstellt. Zu den typischen Fehlern gehören:

1. nicht-deterministische Fehler wie das Speichern mehrerer Daten auf dieselbe Speicherzelle
2. Memorylecks und korrupte Speicherbereiche
3. inkonsistente Speicherreservierung und die dazugehörige Freigabe
4. falsche Benutzung der Speicherschnittstellen
5. Date Races
6. Deadlocks
7. gemeinsamer Speicherzugriff von Threads

Sämtliche Punkte beziehen sich auf mögliche Speicherprobleme, die immer wieder bei der Parallelprogrammierung auftauchen, da hier fehlende Locks oder der unsachgemäße Einsatz globaler Variablen (zum Beispiel innerhalb einer parallel_for-Loop) zum Crash der Anwendung führen können, sobald Daten auf dieselbe Speicherzelle zugreifen. Damit sorgt der Inspector XE 2011 für zuverlässigere Anwendungen.

Praktisch am Inspector ist aber auch dessen Flexibilität: So lässt sich dieses Tool (wie die gesamte Parallel-Studio-XE-Suite) sowohl als eigenständige Entwicklerumgebung einsetzen als auch innerhalb der gewohnten Visual-Studio-IDE als Plug-in nutzen. Zudem unterstützt die Standalone-Variante sowohl Windows als auch Linux. Das macht das Entwicklertool für eine Reihe von Programmierern interessant, für die Parallel Studio nicht infrage kommt.

Und für all diejenigen, die lieber gucken als lesen, haben wir ein knapp 9-minütiges Video aufgespürt, das Intel Inspector XE 2011 recht anschaulich erklärt – wenn auch in englischer Sprache.

Mit dem Intel Inspector XE 2011 lassen sich vor allem Speicherprobleme aufspüren und beheben

Das Ausgangsproblem: Mit den für C++ vorhandenen Templates lässt sich schnell zuverlässiger Code generieren. Die Fertigprodukte sind zuverlässig, lassen sich aber kaum optimieren, etwa hinsichtlich Performance. Der Advisor setzt genau dort an und leistet gute Dienste, indem er auch bei älteren Templates die passenden Threads in die Apps integriert.

Gerade wenn der Durchblick  bei seriellem Code fehlt, was bei fremden Templates häufig der Fall ist, sind Analyse-Instrumente obligat, um zu entscheiden, an welchen Stellen Parallelisierung möglich ist und in der Folge zu deutlichen Leistungsgewinnen führt. Der Advisor beantwortet die offenen Fragen über die Funktion Survey Report. Auf diesem Weg werden Bottlenecks grafisch sichtbar.

Die Funktion Survey Report ermittelt Bottlenecks

Und natürlich hilft das Tolol auch bei der Codebereinigung. Über die Funktion Correctness Report lassen sich die Fehler vorhandener Funktionen im Detail darstellen.

Die Funktion Correctness Report bewertet den Code

Und für das Fixing ist der Correctness Source zuständig. Die Funktion zeigt exakt, an welchen Stellen Parallelisieren hilft.

Den kompletten Beitrag mit weiteren Screenshots und konkreten Code-Beispielen können Sie übrigens hier abrufen. Und wer es noch genauer wissen will: Hier gibt es eine kostenlose und sehr detaillierte Einführung in den Advisor zum Download.

Dabei ging es auch um die noch recht neue Entwicklersuite Intel Parallel Studio XE, über die ich ja hier schon am Montag ein wenig ausführlicher gebloggt habe. Für einige von Ihnen war das sicherlich noch nicht ausführlich genug, und so bekommen Sie hier weitere Details zu den einzelnen Komponenten, die im Entwicklertool von Intel stecken.

Den Anfang macht VTune Amplifier XE 2011, formerly known as VTune Performance Analyzer samt Thread Profiler. Mit VTune Amplifier XE hat Intel also zwei Tools zu einem einzigen verschmolzen, und das aus gutem Grund: denn mit dem ehemaligen Tool VTune Analyzer konnte man als Entwickler zwar recht schnell die vorhandenen Hotspots innerhalb einer Anwendungen finden, nur war die optische Aufmachung des Tools ein wenig gewöhnungsbedürftig, so dass eine Menge an Einarbeitungszeit vonnöten war, um dieses Profiwerkzeug richtig einzusetzen.

Der Thread Profiler hingegen lieferte grafisch aufbereitete Fehleranalysen Ihres Quellcodes, um unter anderem folgende Fragen zu beantworten: “Welche CPU-Ressourcen nutzt meine App kaum oder nur ungenügend?”, “Wie sieht der Verlauf meiner App aus?” und “Wo finde ich die Synchronisationsprobleme laufender Threads?”  Tja, und mit dem VTune Amplifier XE 2011 bekommt man als Software-Entwickler für C, C++ und Fortran ein Tool an die Hand, mit dem sich all diese Aufgaben erledigen lassen, und das unter einer optisch ansprechenden und verständlichen Bedieneroberfläche.

Was also leistet der VTune Amplifier im Detail? Nun, hierzu gehören folgende Aufgaben:

• Mit der Hotspot-Analyse lassen sich diejenigen Codeabschnitte aufspüren, die die meiste Rechenzeit verschlingen. Und per Doppelklick auf die jeweilige Funktion landet man direkt im zugehörigen Quellcode.
• Locks und Waits lassen sich grafisch identifizieren. “Grau” bedeutet vertane CPU-Zeit, “Rot” heißt schwache Auslastung der Prozessoren, “Orange” signalisert “Alles gut”, und “Grün” sagt: “Hier sind die Wartezeiten optimal!”
• Mit der Maus lassen sich kurze Zeitabschitte definieren, die gesondert analyisert und betrachtet werden sollen. Damit können Sie beispielsweise testen, wie lange Ihre App für den Start und das Beenden braucht.
• Das Verhalten von Threads zueinander lässt sich mit dem Analysetool ebenfalls messen. Sie sehen sofort, wie gut es um die Parallelität der Threads bestellt ist.
• Mit dem prozessoreigenen Tool Performance Monitoring Unit (PMU) lassen sich in Verbindung mit VTune Amplifier hardwarenahe Infos wie Cache Misses, Clock Ticks und andere Daten auslesen und darstellen. Dabei erhalten Sie sogar Tipps, an welchen Schrauben Sie drehen können, um die Performance Ihrer Anwendungen weiter zu steigern.

Sie sehen also: Mit VTune Amplifier XE 2011 können Sie Anwendungen unter Windows und Linux auf ihre Parallelfähigkeiten hin untersuchen – und das grafisch und mit vielen nützlichen Zusatzinformationen. Und wer das Ganze in Videoform präsentiert haben möchte, dem empfehle ich einen Ausflug in das Intel Learning Lab, das regelmäßig neue Lernvideos veröffentlicht – auch zu Intel Parallel Studio XE 2011.

Über eines der neueren Tools, das Intel Parallel Studio XE, habe ich in der vergangenen Woche bereits geschrieben.

Parallel Studio XE ist ein unverzichtbares Instrument zum Parallelisieren von C/C++ und Fortran-Apps. Das Tool-Paket stellt Bibliotheken, Analyse- und Performance-Werkzeuge zur Verfügung, dieProgrammierern die Möglichkeit geben, ihre Anwendungen mit bestmöglicher Skalierbarkeit, Verfügbarkeit und Sicherheit auszustatten.

Hier nun die wichtigsten Vorteile von Parallel Studio XE im Einzelnen:

• Plattformunabhängigkeit: Entwickler können ihrenSource Code auf unterschiedliche Betriebssysteme wie Windows, Linux und Mac OS (Compiler und Libraries) ausrichten. Zudem ist Parallel Studio XE mit den aktuellen Entwicklungsumgebungen kompatibel.

• Automatisierung der Code-Verbesserung: In der künftigen Ausrichtung auf Sandy Bridge und Many Core-Prozessoren lassen sich AVX-Befehlssätze mit 256 Bit breiten Registern einfach über die integrierten Compiler nutzen. Der Parallel Composer XE 2011 sorgt für automatische Vektorberechnung und Autp-Parallelisierung.

• Serie von Bibliotheken: Der Intel Composer XE 2011 stellt zudem Intels Parallel Building Blocks zur Verfügung. Diese bieten mit C++-Bibliotheken und Spracherweiterungen hohe Skalierbarkeit und eine höhere Abstraktion. Native Threads müssen nicht mehr verwendet werden. Somit sinkt der Aufwand für die Optimierung von Legacy Code. Fortran-Entwicklern bietet der Fortran-Compiler mehr Funktionalität und verbesserten Support.

• Code-Qualität verbessern: Der Intel Inspector XE prüft auf Speicher- und Thread-Probleme wie Data Races und Deadlocks. Zudem führt er Sicherheitsanalyse durch und deckt Security-Lecks wie Buffer Overruns auf. Entwickler können Fehler korrigieren, bevor diese im Code verwurzelt werden.

• Fortgeschrittene Performance-Tools: Der VTune Amplifier XE führt Performance-Analysen durch und findet Bottlenecks in seriellem und parallelem Code. Das Tool gibt Antworten auf die Fragen „Wo verwendet und verschwendet meine App Zeit? Wo kann ich Wartezeit reduzieren? etc.“

Interesse geweckt? Der Intel-Partner SOS Software Services veranstaltet am 22.2.2011 bei Intel in Feldkirchen einen Info-Event zum Thema „Multicore-Programmierung mit Intel-Tools“. Am 23.2.2011 folgt dann ein Technik-Workshop mit praktischen Beispielen.

Weitere Details dazu sowie eine Anmeldemöglichkeit gibt es unter www.sos-software.com/intelevent

Spannend (und durchaus unterhaltsam) war die Eröffnungsrede von Ralph de Wargny, Business Development Manager bei Intel. Wargny gab tiefe Einblick in die Prozessorentwicklung bei Intel und ging mit seinen Ausführungen auf wichtige Intel-Tools für Software-Entwickler detailiert ein.

Hier die wichtigsten Punkte:

Mit den derzeit verfügbaren Notebook-Chips Core i-3, Core-i-5 und Core i-7  ist Sandy Bridge „state of the art“ für Hochleistungs-Computing in den Bereichen Grafik, Multimedia und Spiele. Die Desktop-Varianten von Sandy Bridge werden in Kürze folgen.

50 Prozessorkerne auf einer Steckkarte

Letztlich ist Sandy Bridge aber vor allem ein Zwischenschritt auf dem Weg zur Generation der Many-Core-Prozessoren. Intels künftige „Many Integrated Core Architektur“ (MIC) wird 22nm-Chips hervorbringen. Kleiner, leistungsstärker und mit bis zu 50 Cores. Ein solcher Prozessor ist unter der Bezeichnung „Knights Corner“ in Planung. Diese Chips ergänzen die Leistung vorhandenere Prozessoren, indem sie auf einer Steckkarte als Coprozessoren integriert werden. Klingt nach Flexibilität und enormer Usability. Allerdings gibt es dafür noch keinen genauen Zeitplan.

Intel Parallel Studio in der Praxis

Wargny sprach zudem ausführlich über die aktuellen Intel Entwickler-Tools wie Parallel Studio XE und Parallel Studio.  Beide bieten ein Set an effizienten Werkzeugen wie Compiler, Bibliotheken und Analyse-Tools. Im Vordergrund hierbei stehen eine maximale Skalierbarkeit von Software-Anwendungen und umfassendes Performance Measurement. Damit sind sie für Multicore-Programmierer unverzichtbar.

Der Unterschied zwischen den beiden: Parallel Studio XE (XE steht übrigens für eXtreme Edition) ist ein Standalone-Produkt, das sich in unterschiedlichen Systemumgebungen wie Windows oder Linux einsetzen lässt. Parallel Studio hingegen ist ein Plug-In für Visual Studio von Microsoft. Diese Version stellt mit dem Parallel Advisor ein sehr gutes Einsteigerwerkzeug bereit, das enorme Hilfe beim Parallelisieren des Codes leistet.

In einem meiner künftigen Beiträge werde ich mir Parallel Studio XE näher ansehen und die Vorteile für Parallel-Programmierer detailliert beschreiben. Zudem habe ein Interview mit Ralph de Wargny geführt. Das zugehörige Video können Sie hier ebenfalls in Kürze abrufen.

Update: Das Video ist fertig und steht zum Ansehen bereit.

Heute freue ich mich aber erst einmal auf den Vortrag „Introducing parallelism into legacy code: Three case studies“ von Stephen Blair-Chappell. Auch hierüber werde ich natürlich berichten und mit Stephen ein kurzes Interview führen.

Alle Fotos von der Keynote der OOP können Sie übrigens über die neue Flickr-Seite des Software Dev Blogs abrufen und selbstverständlich auch für Ihre eigenen Zwecke nutzen.

Der wesentliche Unterschied zwischen SSE4 und AVX ist die Registerbreite, die von 128 auf 256 Bit erhöht wurde und damit doppelt so schnelle Vektorberechnungen ermöglicht – na ja, zumindest theoretisch.

Und wie sieht das Ganze in der Praxis aus? Nun, mihilfe der AVX-Erweiterungen lassen sich bis zu vier Gleitkomma-Operanden mit doppelter Genauigkeit (64 Bit) in einem einzigen Vektor zusammenzufassen. Auf dieser Basis lassen sich mit diesem so entstandenen Vektor arithmetische und logische Operationen durchführen. Damit kann zum Beispiel die Addition zweier Vektoren [x,x,x]+[y,y,y] in einem einzigen Zyklus erledigt werden. Bei skalaren Berechnungen sind vier Taktzyklen erforderlich. Ein Nachteil haben die doppelt so breiten Register natürlich auch: die Datenpfade müssen entsprechend größer sein.

Was man mit AVX alles Schönes anstellen kann, zeigt die Intel-AVX-Seite, die ich hier mal verlinkt habe. Dazu gehören unter anderem:

• Normalisierung von 3D-Vektoren
• Inverse Transformationen von Diskreten Kosinus-Funktionen
• Implementierung eines Gauss’schen Blur-Filters
• usf.

Darüber hinaus findet man auf dieser Seite weitere Infos rund um AVX. Dazu gehört beispielsweise das brandneue Tool Intel Architecture Code Analyzer, mit dem sich bestehender Quellcode auf mögliches AVX-Optimierungspotenzial hin untersuchen lässt. Aber auch Infos zum Intel Software Development Emulator finden Sie auf der AVX-Seite. Und wem das alles zuviel  Englisch ist, sollte regelmäßig auf dem Software Dev Blog vorbei schauen. Denn hier gibt es in den nächsten Wochen immer wieder Infos rund um AVX, Sandy Bridge und Co.

In wenigen Tagen wird Intel während der CES in Las Vegas die neue Prozessorgeneration Sandy Bridge offiziell vorstellen. Vor Ort werden dann auch gleich ein paar Hardware-Hersteller erste Notebooks mit den neuen Recheneinheiten zeigen.

Die Prozessor-Architektur von Sandy Bridge wird vor allem in puncto Multimedia-Performance alle Vorgänger der Nehalem-Bauweise in den Schatten stellen. Sandy Bridge integriert den Grafikkern (GPU) in die CPU bei einer Strukturbreite von 32 Nanometern. Dank der integrierten Encoding-Einheit lassen sich Videos wesentlich schneller konvertieren als beispielsweise mit bekannten Core-i5-Prozessoren.

Die technologischen Neuerungen von Sandy Bridge und die daraus resultierenden, erweiterten Möglichkeiten für Parallel-Computing sind Anlass genug, dieses Blog wiederzubeleben. Ich werde Sie ab sofort regelmäßig mit News, technischem Background und Veranstaltungshinweisen versorgen, die Ihnen den Programmieralltag etwa erleichtern.

Zunächst aber darf ich Ihnen zwei neue, sehr nützlich Tools empfehlen, die Intel im Rahmen der Partnerprogramme veröffentlich hat und vor allem Entwickler von Media- und Videoanwendungen adressieren.

Das Intel Media Software Development Kit in der Version 1.5 ist ein plattformübergreifendes SDK, das Ihnen hilft, auf einfache Weise leistungsstarke und schnelle Videoanwendungen zu entwickeln.  Das Tool-Paket bietet Ihnen drei Highlights:

• Codecs für Hardwarebeschleunigung: Sie greifen auf Video-Codecs zu, die für Intel Multicore-Prozessoren und Intel HD Graphics optimiert wurden und bestmögliche Performance bieten
• Einheitliches API für unterschiedliche Plattformen: Weniger Code und weniger Komplexität durch ein universelles API, das viele PC-Plattformen unterstützt, darunter selbstverständlich auch die zukunftsträchtigen Intel Graphics- und Multicore-Architekturen.
• Support und Add-Ons: Schneller optimale Ergebnisse erzielen dank nützlicher Features wie Video-Pre-Processing, Decodieren und Encodieren

Sie können das Media Software Development Kit kostenlos laden und installieren. Sinnvoll ergänzt wird das SDK durch das Intel Media Checker Software Assessment Tool. Zugegeben, eine grauenhafte Bezeichnung, aber das Tool ist überaus nützlich. Denn damit stellen Sie beispielsweise sicher, dass Sie das SDK korrekt in die Anwendungen einbinden. Zudem fungiert es als Tutorial, indem es die Funktionen und Technologien des SDK erläutert. Also für die ersten Schritte mit dem SDK sicherlich genau richtig. Und kostenlos ist es natürlich auch. Viel Erfolg damit!

Den Anfang macht ein kleines, unscheinbares Tool, dass sich Intel Parallel Advisor nennt, Teil des Intel Parallel Studio 2011 ist und Software-Entwicklern dabei helfen soll, nativ programmierten Code schneller, effizienter und einfacher zu parallelisieren. Dabei geht der Advisor sehr systematisch vor, um die bestmöglichen Ergebnisse in Sachen parallelisierter Quellcode zu erreichen. Hierzu sind fünf Schritte notwendig:

1. Survey Target: Im ersten Schritt wird der Quellcode auf mögliche Hotspots untersucht und dabei festgestellt, welche Abschnitte innerhalb des Programms besonders für eine Parallelisierung in Frage kommen.

2. Annotate Sources: Anschließend fügt der Advisor in die identifizierten Quellcodestellen sogenannte Annotationen ein, also entsprechende Pseudo-Befehle, die das Parallelisieren ermöglichen sollen. Dieser Abschnitt ist als eine Art Experiment zu sehen, mit dessen Hilfe man die bestmöglichen Ansätze für Parallelcode finden soll.

3. Check Suitability: Nachdem man die Annotationen in den seriellen Quellcode eingefügt hat, macht sich der Parallel Advisor per Mausklick daran, die vorgenommenen Änderungen des Programms auf Machbarkeit hin zu überprüfen. Hierbei wird vor allem festgestellt, was die Veränderungen zur Laufzeit tatsächlich bringen, ob sich ein Parallelisieren an dieser Stelle also überhaupt lohnt.

4. Check Correctness: Der vierte Schritt hat vor allem mit möglichen Speicherproblemen zu tun. Dabei überprüft der Parallel Advisor wiederrum per Mausklick, welche Dead Locks, Data Races und andere möglichen Probleme anhand der vorgenommenen Änderungen des ursprünglich seriellen Quellcodes zu erwarten sind. Dies ist bei der Umstellung von seriell auf parallel ein kritischer Punkt, den man auf keinen Fall unterschätzen darf. Mögliche Speicherfehler lassen sich nämlich mit herkömmlichen Testverfahren oder Debuggern nur ganz schwer oder gar nicht aufspüren.

5. Add Parallel Framework: Sobald der Parallelcode keine Fehler mehr aufweist und sämtliche Speichertests ohne Probleme durchgeführt werden konnten, müssen nur noch sämtliche Annotationen durch entsprechende Konstrukte und Funktionsaufrufe ersetzt werden. Dabei kann man aus einer Reihe von unterstützten Programmiermodellen wie Intel Threading Building Blocks, Intel Cilk Plus und anderen auswählen – je nachdem, welches Modell besser zum ausgewählten Quellecodeabschnitt passt.

Ach ja: Bilder und weitere Erklärungen zum Intel Parallel Advisor bekommt ihr noch diese Woche auf dem Software Dev Blog. So, stay tuned…

Den Anfang macht der System Analyzer, mit dem sich in Echtzeit analysieren lässt, was während des Gameplays alles passiert. Um das Testsystem von rechenintensiven Aufgaben zu befreien, läuft der System Analyzer auf einem anderen Rechner als das zu testende Spiel. Dabei stehen verschiedene Funktionen wie die CPU-Diagnose, das Ermitteln der Anzahl der Locks per Frame und der Framerate selbst sowie andere wichtige Parameter zur Verfügungung.

Praktisch am System Analyzer sind die vorhandenen Hardware-Diagnose-Tools, mit denen sich auf Intel-Systemen Dinge wie die Auslastung der vorhandenen Execution Units untersuchen lassen. Aber auch bestimmte Ansichten auf die aktuelle Spielszene erlauben das Analysieren des Spiels. So lassen sich beispielsweise mit der Gitterdarstellung verborgene Objekte entdecken, die dort gar nicht hingehören und nur überflüssige Rechenzeit verbraten.

Der Frame Analyzer geht dann richtig in die Tiefe und lässt jedes einzelne Bild eines Spiels analysieren. So kann man anhand der DirectX-Drawcalls feststellen, welche Bereiche eines Frames besonders viel Rechenzeit beanspruchen und diese Bereiche gegebenenfalls optimieren. So zeigen beispielsweise versteckte Objekte hohes Optimierungspotenzial, da sie zum Gameplay nichts beitragen, aber trotzdem Rechenzeit kosten. Um die möglichen “Störenfriede” zu eliminieren, kann man aber auch experimentell vorgehen, indem man einzelne Parameter ausschaltet um zu sehen, wie sich das auf die Szene und die Renderleistung auswirkt.

Das dritte Tool schließlich, Platform View, ist zum einen “neu” in der Version 3.0 von Intel GPA und bietet zum anderen einen detaillierten Blick auf den Parallelisierungsgrad des Spiels. Dabei kann man sich sämtliche Threads anzeigen lassen, die gerade aktiv sind und diese in der Detailansicht genau analysieren. So lässt sich beispielsweise herausfinden, warum die CPU auf die GPU warten muss oder auch anders herum.

Zum Thema “Nächste GPA-Version” konnte wir den dafür zuständigen Intel-Mann Aaron Davies überreden, vor der Kamera ein wenig in seine Glaskugel zu blicken. So verriet er uns, dass die nächste Version Anfang kommenden Jahres zur GDC 2011 in San Francisco vorgestellt wird. Dass Intel GPA 4.0 für die nächste Prozessorgeneration Sandy Bridge optimiert sein wird, überrascht genauso wenig wie die Tatsache, dass das Analysetool die noch in der Beta-Phase befindliche Platform View integrieren wird, da es sehr postives Feedback seitens der Entwickler gab. Die gute Nachricht: Intel GPA und andere Tools von Intel bleiben kostenlos für Entwickler, da der Chiphersteller seine große Fangemeinde weiterhin mit dieser Art der Dienstleistung beglücken will.

Von der Zukunft zurück in die Gegenwart ging es dann mit Mario Deilmann, der es sich zum Ziel gesetzt hatte, die anwesende Entwicklerschar während seiner Techsession davon zu überzeugen, dass mit Intel TBB ein Tool zur Verfügung steht, mit der sich Spieletitel an vielen Stellen parallelisieren lassen. Wie er anschließend vor unserer Kamera verriet, lieben Spieleentwickler Open-Source-Tools wie Intel TBB, da sie die gesamte Kontrolle über den Sourcecode des Tools haben. Auf der anderen Seite gibt es natürlich eine kommerzielle Version von Intel TBB für diejenigen, die auf Support nicht verzichten wollen.

Gut an Intel TBB ist aus Marios Sicht vor allem, dass sich der zu parallelisierende Code nicht mehr als Low-Level-Threads, sondern als abstrahierte Tasks darstellen lässt, was die Parallelisierung von Spielen erheblich vereinfacht. Aber auch die verschiedenen Abstraktionsebenen machen aus Intel TBB ein echtes Gaming-Dev-Tool. So kann man mit Konstrukten wie Concurrent Container und Concurrent Allocator genauso arbeiten wie mit Low-Level-APIs wie dem TBB Scheduler, um damit die besten Ergebnisse zu erzielen. Einen weiteren Pluspunkt sieht Mario in der Plattformunabhängigkeit von Intel TBB, das von Windows, Mac OS und anderen Betriebssystemen und Plattformen unterstützt wird.

Last but not least hatten wir gegen Ende der GDCE 2010 die Gelegenheit mit Dierk Ohlerich zu reden. Dierk ist Head of Technology bei 49Games aus Hamburg, die sich vor allem auf Konsolentitel aus dem Bereich Sportsimulationen konzentrieren. In seinem Videointerview erzählt er uns, dass er seine eigene Task-Stealing Engine geschrieben hat, mit deren Hilfe Spiele optimal auf unterschiedlichen Multicore-Systemen skalieren.

Das Hauptziel seines Projekts ist die Integration einer solchen Task-Stealing Engine in die Rendering Pipeline. Dabei galt es jedoch diverse Klippen zu umschiffen wie das genaue Vorhersagen des Datenaufkommens, wofür dynamische Datenspeicher notwenig sind. Aber auch die richtige Reihenfolge beim “Zeichnen” einer Spielszene stellt laut Dierk ein echte Herausforderung dar, wenn es um das Parallelisieren der Render Engine geht.

Das UDK bietet so ziemlich alles, was man als ambitionierter Spieleentwickler braucht. Neben Unreal Engine 3 bietet es beispielsweise das integrierte Beleuchtungsmodell Lightmass, mit dem sich Lichteffekte wie Reflektionen von Glanzlichtern und verstreute Lichtquellen im Offline-Modus, also vorab, berechnen lassen. Und da UE3 höchst Multicore-optimiert ist, profitieren Game-Entwickler bei der Berechnung von Spielszenen und -Leveln von den schnellen 8- oder 12-Core-Prozessor-Maschinen, in denen eine Intel-CPU werkelt.

Aber auch die Möglichkeit, mithilfe von Unreal Swarm komplexe 3D-Berechnungen nicht nur von einem, sondern von einem ganzen Rechnernetzwerk durchführen zu lassen, spricht für Unreal Engine 3, respektive Unreal Developer Kit. Und auch weitere Features wie das Unreal Build Tool, Navigation Meshes und der Content Browser machen aus Unreal Engine 3 eine extrem leistungsfähige Entwicklerplattform für aufwändige 3D-Spiele. Und das alles für umsonst?! Kaum zu glauben…

• Intel GPA steht derzeit in der dritten Version kostenlos zum Download bereit, was lediglich mit einer kurzen Registrierung verbunden ist.

• Mit Intel GPA lassen sich DirectX-Spiele untersuchen (DirectX 9 und 10), aber auch das PC-System kann zur Spiele-Laufzeit untersucht werden. Damit lassen sich beispielsweise CPU-Lasten ermitteln und wie das Spiel auf Basis der vorhandenen Ressourcen skaliert.

• Mit Intel GPA lassen sich aber auch einzelne Spielszenen (Frames) untersuchen und herausfinden, wie sich diese in Sachen Funktionsaufrufe, etc. verhalten. Damit weiß man ziemlich genau, an welchen Stellen es “klemmt” und auf dieser Erkenntnis kann man probehalber einzelne Prozessorkerne “abschalten”, neue oder aufwändigere Texturen laden oder den Shader “umschreiben”, um somit eine optimierte Variante der betreffenden Szene zu erhalten. Denn oft sind es Kleinigkeiten, die ein 3D-Game ausbremsen.

• Mit Intel GPA lässt sich zwar nicht nur Intel-Grafikhardware adressieren, aber aufgrund der architektonischen Unterschiede gelingt dies natürlich am besten. Damit kann man genau messen, wieviel Bandbreite die verwendeten Texturen beanspruchen, wie viel Rechenzeit die Shader verbraten, etc. Damit weiß man ganz genau, an welchen Stellen es klemmt – und was man tun sollte, um diese Flaschenhälse zu beseitigen.

Tja, und den Rest schaut ihr euch am besten selbst an. Film ab!

Die einzelnen Bereiche und Tools wurden wie folgt an die moderne CPU-Architektur angepasst:

• Sämtliche Anwendungen wurden einem Multithreading unterzogen, was unter anderem schnelleres Öffnen und Speichern von Dokumenten ermöglicht.

• Beim Starten von Outlook werden mehrere Threads gleichzeitig gestartet, was dazu führt, dass parallel die Bedieneroberfläche aufgebaut, die Kalendereinträge geladen und die Voransicht der erhaltenen E-Mails angezeigt werden. Jeder Task bekommt also seinen eigenen Thread zugewiesen.

• Word erledigt dank Multithreading die Paginierung im Hintergrund, was Raum für andere Aufgaben zur selben Zeit lässt.

• In Excel werden Pivot-Tabellen parallel und damit deutlich schneller sortiert.

• Multithreading wird in Excel aber auch dazu eingesetzt, Berechnungen in den Hintergrund zu schieben, während gleichzeitig grafisch orientierte Arbeiten wie das Ändern der Zeilenhöhe oder das automatische Anpassen der Zellenbreite an die Inhalte vorgenommen werden.

Allerdings stand Microsoft beim Optimieren von Office 2010 an Multicore-Rechner vor einem erheblichen Problem: Wie können Tools wie Word oder Excel so verbessert werden, dass sie die häufigen Wartezeiten, die sich bei der Mensch-Maschine-Interaktion ergeben, möglichst minimieren? Daher wurden diejenigen Flaschenhälse identifiziert, die sich beispielsweise beim Start der Anwendung oder beim Öffnen oder Speichern einer Datei ergeben und Wartezeiten verursachen. Daran wurde dann verstärkt gearbeitet.

Nur setzt Microsoft immer noch sehr auf das funktionale Multithreading, bei dem die unterschiedlichen Aufgaben der Software eigenen Threads zugewiesen werden. Das ist zwar nicht sehr effizient (da diese Methode nicht optimal skaliert), aber wohl angesichts der hohen I/O-Aktivitäten zu vernachlässigen.

Auf den ersten Blick bietet Intel TBB 3.0 zwei wesentliche Verbesserungen: die volle Kompatibilität mit Visual Studio 2010 und .NET 4 sowie die Unterstützung des künftigen ISO/ANSI-Standards für C++, der noch unter dem Arbeitsnamen C++0x geführt wird. Aber auch andere Features wie eine neue Containerklasse und verbesserte Debugger-Merkmale flossen in die neue Version der Intel TBB 3.0 ein. Im Detail sieht das wie folgt aus:

Optionaler C++0x-Support

• die neue Funktion parallel_pipeline() verbessert die alte Warteschlange-Funktion mithilfe von Lambda-Support und anderen Features
• TBB_USE_CAPTURED_EXCEPTION() verbessert das Exception Handling
• verbesserte Synchronisierung auf Basis konditioneller Variablen

Handbuch “Pattern Design”
Dieses von TBB-Entwickler Arch Robison geschriebene Handbuch zeigt, wie Pattern Design funktioniert

Kompatibel mit Microsoft Visual Studio 2010

• Support der Concurrency Runtime
• kompatibel mit der Parallel Pattern Library
• kompatibel mit reader_writer_lock() and critical_section_lock()

Neue Container-Klasse
concurrent_unordered_map() (natürlich C++ 0x-kompatibel)

Verbessertes Debuggen

• Task Scheduling, Vorhersagen und Reaktionszeiten wurden verbessert
• voneinander unabhängiges Verwalten von Tasks für mehrere Masterthreads
• verbesserte Vermeidung von Deadlocks
• weiterentwickelte Hinweise für Parallel Amplifier und Parallel Inspector

Scheduler-Support (task::enqueue)

• unterstützt FIFO-Warteschlagen
• nützlich für das  Emulieren von Task-Prioritäten und die Interaktion mit GUI-basierten Threads

Leistungsverbesserungen

• Beschleunigung der Funktion numerable_thread_specific() und Kombinationen davon
• verbesserte Speicherverteilung bei großen Speicherblöcken

und einiges mehr.

Wer mit Intel Threading Building Blocks Software entwickeln und parallelisieren möchte, kann dies in zweierlei Hinsicht tun: entweder bezahlt man 299 Dollar für die Windows- oder Linux-Variante und erwirbt damit das kommerzielle Paket von TBB 3.0. Dazu gehört auch ein professioneller Support seitens Intel. Oder man begibt sich auf www.threadingbuildingblocks.org, besorgt sich die Open-Source-Variante des Pakets und bekommt damit eine GPLv2-Lizenz. Diese ist natürlich kostenlos.

Das wird sicherlich auch noch ein wenig so bleiben, was aber nicht bedeutet, dass auf dem Software Dev Blog die parallele Verarbeitung von Programmcode keinen Platz mehr findet. Um dies unmittelbar zu belegen, möchte ich heute auf eine sehr ausführliche Übersicht aufmerksam machen. “Ultimativ” klingt immer ein wenig anbiedernd und angeberisch, aber in diesem Fall kommt der Begriff ziemlich nah an das heran, was die amerikanischen Kollegen unter dem Titel “Intel Guide for Developing Multithreaded Applications” zusammengetragen haben.

Diese wirklich umfangreiche Sammlung betrachtet sämtliche Aspekte der Parallelprogrammierung. Ob das das Multithreaden von Anwendungen im Allgemeinen ist oder spezielle Themen wie die Daten- und Ablaufsynchronisation oder das Speichermanagement – so detailliert konntet ihr euch dem Thema wohl selten widmen. Ok, das Ganze findet zwar auf Englisch statt, aber das sollte doch keine echte Hürde darstellen.

Ach ja, natürlich darf eine genaue Beschreibung sämtlicher Intel-Tools nicht fehlen, wenn es um das Multithreaden von Anwendungen geht. Also so Themen wie Intel Compiler, Parallel Inspector, OpenMP, Parallel Amplifier und viele mehr. Na, dann kann ich euch nur noch “Gut Stöber” wünschen und dass ihr möglichst viele Antworten auf eure parallelen Fragen findet. Die gibt es natürlich auch hier auf dem Software Dev Blog. Probiert doch einfach mal die Suchfunktion aus!

Ein wesentlicher Punkt ist unter anderem der Einsatz des Intel C++ Compilers, der laut Maxon schon mal ohne nennenswerte Änderungen am Code etwa 15 Prozent mehr Speed bringt. Aber auch der Intel Thread Profiler steht bei Maxon ganz oben auf der Liste, wenn es darum geht herauszufinden, wie sich das parallelisierte Programm verhält, ob also die anfallenden Threads möglichst gleichmäßig auf die vorhandenen Ressourcen verteilt werden (Skalierung ist hier das Zauberwort).

Darüber hinaus kommen VTune Performance Analyzer und Intel Threading Building Blocks zur Sprache. Ok, dann würde ich mal sagen, den Rest solltet ihr euch am besten selbst ansehen. Viel Spaß dabei!

Ende August war ich bei Apple, um ein wenig mehr über deren Multicore-Beschleuniger Grand Central Dispatch zu erfahren. Diese in Snow Leopard implementierte Technik erlaubt es Anwendungsentwicklern, mit relativ wenig Aufwand, ihre Anwendungen multicore-tauglich zu machen. Und das ohne größeren Programmieraufwand, sondern lediglich mithilfe der C-API und den NSOperation-Klassen.

Das Tolle an GCD ist deren einfache Verwendung: Anstatt selbst Threads auf Basis von Tasks oder anderen Objekten zu erzeugen, kümmert sich GCD selbst darum. Das bedeutet aber für den Software-Entwickler, dass er sich für eine optimale Ausnutzung der vorhandenen Prozessorressourcen grundsätzlich Gedanken machen muss über die Programmlogik. Das Resultat seines überarbeiteten Programms sind einzelne Tasks, die je nach Programmablauf an die vorhandenen Multithreading-Queues übergeben werden können, wo sie von GCD bestmöglich verarbeitet werden.

Wie bereits angedeutet, stellt GCD zwei Möglichkeiten zur Verfügung, Programmcode zu multithreaden: Mithilfe der NSOperation-Klasse und der C-API. Beides soll kurz beleuchtet werden.

NSOperation: Warteschlangentechnik für asynchrone Tasks
Für das asynchrone, also zeitversetzte Ausführen von Anwendungen ist lediglich das Erstellen von NSOperation-konformen Objekten erforderlich, die dann an die zugehörige Warteschlange übergeben werden, die die Queue nach dem FIFO-Prinzip verarbeitet. Hierfür werden Tasks im Hintergrund ausgeführt, pausiert und zu Ende geführt. Es ist sogar möglich, die Anzahl der maximalen Threads festzulegen, was in Extremfällen ein einziger sein kann. Natürlich erlaubt GCD die ständige Rückkehr zum Main Thread.

Sehr hilfreich ist auch das “Verketten” mehrerer Threads, um so bestimmte Abhängigkeiten zu definieren. Hierzu gehört auch die Möglichkeit, Thread zu priorisieren. Darüber hinaus lassen sich NSOperation-Threads mit Rückgabewerten definieren, die während des Programmablaufs dann weiter verwendet werden können.

Grand-Central-Dispatch-API
Neben den NSOperation-Klassen erlaubt die GCD-API das direkte Verwenden der vorhandenen Funktionen. Hierfür kann man entweder eigene Queues erzeugen oder auf die globale Warteschlange zugreifen. Es existieren drei globale Queues, die sich lediglich in ihrer Priorität unterscheiden. Daneben gibt es natürlich auch eine Main Queue, die die Steuerung des Main Threads übernimmt.

Im Gegensatz zu den globalen Queues funktionieren eigene Warteschlange rein seriell, womit sie beispielsweise in Bereichen eingesetzt werden können, die bis dato mit Hilfe von Locks überwacht wurden. Queues werden blockweise gefüllt, der zugehörige Code wird asynchron im Hintergrund ausgeführt. Für eine problemlos Rückkehr zur Main Queue sollte jeder Block eine Callback-Funktion aufweisen, die auf das “Hauptprogramm” verweist. Natürlich lassen sich Queues auch pausieren (suspend) und weiter ausführen (resume).

Weitere wichtige GCD-Techniken
Neben den Klassen und APIs stehen weitere Techniken in GCD zur Verfügung, die man als Entwickler kennen sollte. So ermöglichen beispielsweise Semaphore die bessere Kontrolle bgrenzter Ressourcen. Aber auch Deadlocks lassen sich dank GCD besser vermeiden, Blöcke können zeitlich gesteuert genutzt werden, Systemereignisse lassen sich effizient und einfach überwachen und vieles mehr.

Für ein paar weitere detaillierte Informationen rund um diesen Service hatte ich gestern Abend die Gelegenheit, an einer Telefonkonferenz mit James Reinders teilzunehmen. James ist Director Intel Software Development Products und beschäftigt sich schon seit vielen Jahren mit dem Thema Parallelprogrammierung. So springt er beispielsweise gerade auf der Supercomputing Conference 2009 herum, um dort vermutlich unter anderem sein paralleles Universum vorstellen. Von ihm erfuhren wir ein paar sehr interessante Details zum neuen Cloud-Service:

• Technisch gesehen ist es nicht nur ein Cloud-Rechner, sondern es sind bis zu drei Nehalem-basierte Server, die mit jeweils zwei Quadcore-CPUs bestückt sind. Das ermöglicht inklusive Hyperthreading 16 echte und parallele Hardware-Threads. Sollte ein Parallelrechner nicht ausreichen, werden ein oder zwei weitere automatisch dazugeschaltet. Dies bleibt dem Anwender natürlich vollständig verborgen. In Zukunft werden je nach Erfolgt von Intel Parallel Universe leistungsfähigere Maschinen eingesetzt, mit denen sich auch mehr parallele Threads simulieren lassen. Aber für die aktuellen Anwendungen ist eine Skalierung von maximal 16 Threads völlig ausreichend.

• Sämtliche Analysen, die von Software-Entwicklern eingereicht werden, wandern in eine Warteschlange, sodass es zwar Wartezeiten geben kann, diese allerdings kaum auffallen werden, da die Ergebnisse unmittelbar nach deren Berechnung im Webbrowser dargestellt werden.

• Aufgrund der Beschränkung von 10 Megabyte pro Zip-Datei, die man zu Analysezwecken hochladen kann, empfiehlt James eine sinnvolle “Stückelung” des zu überprüfenden ausführbaren Codes. Es sollten daher vor allem diejenigen Teile einer Anwendung getestet werden, in denen einerseits das größte Parallelisierungspotenzial steckt und andererseits mögliche Bugs in Sachen Skalierbarkeit wahrscheinlich sind. Das zwingt den Programmierer gleichzeitig dazu, über die wirklich relevanten Teile seiner Software nachzudenken, in denen es auf die maximale Performance ankommt.

• Beim Bewerten der Skalierbarkeit einer App sollte man berücksichtigen, dass vor allem datenbasierte Anwendungen besonders gut von Hyperthreading profitieren.

• Um mögliche Risiken von außen zur minimieren (Einschleusung von Malware auf die Cloud-Server u.ä.) hat Intel natürlich diverse Sicherheitsmaßnahmen ergriffen. Dazu gehört auch eine vollständige Protokollierung der Aktivitäten auf dem Rechner, was in Kombination mit der Intel-ID potenzielle Störversuche gut kontrollierbar macht.

Falls ihr weitere Infos rund um Intel Parallel Universe braucht, könnt ihr eure Fragen jederzeit per Kommentarfunktion an mich richten. Ich leite diese gerne an James weiter.

Damit es erst gar nicht so weit kommt, stellt Intel seit Ende Mai dieses Jahres für C- und C++-Anwendungen Parallel Studio zur Verfügung. Mit diesem Plug-in für Visual Studio lassen sich nicht nur möglichst fehlerfreie, sondern auch möglichst skalierende Programme entwickeln, die je nach Anzahl der verfügbaren Prozessorkerne möglichst linear ablaufen. Soll also heißen, dass bei zwei Kernen eine Anwendung doppelt so schnell läuft, auf vier Kernen viermal so schnell usf. – theoretisch zumindest.

Doch wer hat schon unbedingt einen Quadcore- oder noch leistungsfähigeren Rechner im Testlabor rumstehen, mit dem sich diese Skalierung effizient und zuverlässig testen lässt? Eben. Und hier kommt ein ganz neuer Cloud-Service von Intel zum Einsatz, der seit heute kostenlos verfügbar ist. Sein Name: Intel Parallel Universe. Seine Idee: Das Testen parallelisierter Apps mithilfe eines 16-Core-Rechners, der via Internet zur Verfügung steht. Die Voraussetzungen: ein Internetbrowser, Zugang zum Intel Software Network und Parallel Studio für weitere Auswertungen und Analysen.

Der Weg dorthin ist recht einfach: Mit einem kompatiblen Webbrowser (Internet Explorer, Firefox, Safari oder Chrome) lädt man die lauffähige, parallelisierte Windows-Software (32 Bit only) auf Paralleluniverse.intel.com und befolgt die entsprechenden Schritte. Dabei ist es wichtig, dass neben der Anwendung selbst sämtliche Daten und Parameter als Zip-Datei hochgeladen werden (Programme mit Benutzereingaben werden also nicht unterstützt). Sobald dies geschehen ist, wird die Software ausgiebig auf Bottlenecks untersucht. Die Resultate werden dann grafisch aufbereitet und im Webbrowser anschaulich dargestellt. So kann man auf einen Blick erkennen, wie sich die Anwendung auf 1, 2, 4, 8 und 16 Prozessorkernen verhält.

Man sieht also beispielsweise, wie lange die Software auf einer bestimmten Anzahl von CPUs läuft und an welchem Punkt die App nicht mehr skaliert. Aber auch die Parallelität der Anwendung lässt sich feststellen, wie viele Threads also je nach Anzahl verfügbarer Prozessorkerne parallel ausgeführt werden. Doch das ist natürlich nur der Anfang, da man jetzt zwar weiß, ob es klemmt, wo dies allerdings der Fall ist, weiß man noch nicht. Daher lässt sich das Ergebnis der cloud-basierten Analyse lokal speichern und in Parallel Studio öffnen. Der betreffende Sourcecode wird automatisch geladen und per Doppelklick landet man genau an den Stellen, die die mangelhafte Parallelität verursachen. Vermutlich war es noch nie einfacher, Bottlenecks im eigenen Programm zu finden, oder?!

Zum einen werden die Rapidmind-Produkte und Lösungen in Zukunft von Intel vermarktet, was deren Reichweite natürlich drastisch erhöht. Zum anderen kommt Intel in den Genuss, die volle Bandbreite – sowohl technologisch als auch ressourcen-seitig – von Rapidmind zu nutzen. Und das geht meines Erachtens in diverse Richtungen.

Rapidmind-Tools wie Code Optimizer, Load Balancer, Data Manager und Diagnostics sind möglicherweise sehr gute Ergänzungen zu den vorhandenen Intel-Werkzeugen wie Parallel Studio, Thread Checker und Intel TBB. Vor allem, wenn man die Bandbreite der unterstützten Hardware seitens der Rapidmind-Tools genauer betrachtet: Ok, AMD-Prozessoren wird Intel wohl nicht im Visier haben, aber Grafiklösungen wie die kommende Larrabee-Plattform waren für Intel sicherlich ein wichtiger Kaufgrund.

Auch die Nähe der Rapidmind-Werkzeuge zu Embedded Hardware ist für Intel sehr interessant. Denn das IDF steht vor der Tür, und was könnte dort angekündigt werden? Genau, die nächste Generation des Atom-Prozessors. Und der könnte ja mit zwei Prozessorkernen ausgestattet sein. Dann kommt Rapidmind erst richtig zum Zug.

Und nicht zuletzt der Blick auf die unterstützten Betriebssysteme lässt den Deal zwischen Intel und Rapidmind logisch erscheinen. Neben Mac OS X und Windows stehen nämlich diverse Linux-Distributionen auf der Liste der kompatiblen Rapidmind-Produkte. Unter anderen wird das Linux-Derivat Fedora unterstützt. Und wo steckt Fedora drin? Na? Stimmt, im Intel-eigenen Linuxprojekt Moblin, das ja hauptsächlich auf Netbooks laufen soll, in denen möglicherweise demnächst Dualcore-Atom-CPUs werkeln. So kommt dann eins zum anderen, oder?!

Na, wir werden sehen, wie sich das Ganze entwickelt. Ich werde mir auf dem Intel Developer Forum auf jeden Fall die Zeit nehmen, die Rapidmind-Produkte aus nächster Nähe zu begutachten und mit den zuständigen Entwicklern über meine Vermutungen zu reden. Und vielleicht gibt’s ja dann auch schon mehr in Sachen Atom-Prozessor zu berichten.

Hallo,

vor wenigen Minuten solltest Du die Pressemeldung zu Mac OS X Snow Leopard bekommen haben. Am Freitag, 28. August, etwas früher als erwartet, ist die neue Version des fortschrittlichsten Betriebssystems der Welt erhältlich!

Wir möchten Dich noch am selben Tag zu einem kurzen Pressebriefing zur neuen Version des Desktop-Betriebssystems einladen, um Dir einige der Wichtigsten der neuen Verbesserungen und Technologien vorzustellen – von ‘Grand Central Dispatch’ (GCD) bis zur serienmäßigen Unterstützung für Microsoft Exchange.

Lust und Zeit aus erster Hand alles über Mac OS X Snow Leopard zu erfahren, mit den Fachleuten zu diskutieren und selbstverständlich im Anschluss an das Briefing eine Version der neuen Software mitzunehmen?!

Ob ich Lust und Zeit habe?! Na klar habe ich. Denn ich will endlich ein wenig mehr wissen über die geplanten Features des Schneeleoparden, wenngleich es kein ganz großes Update wird. Aber eins steht schon fest: Apple spendiert seiner sechsten OS-X-Version ein neues Tool, mit dem das Programmieren von Multicore-Anwendungen einfacher werden soll: Grand Central Dispatch (GCD).

GCD wird Bestandteil des OS-X-Kernels sein und damit nicht anwendungs-, sondern betriebssystem-nah arbeiten. Und das wiederum soll eine Vereinfachung der Multicore-Programmierung mit sich bringen, da nicht mehr einzelne Multithread-Anwendungen aufeinander abgestimmt werden müssen. Hierfür soll GCD die globale Verwaltung der notwendigen Threads übernehmen und nicht mehr benötigte Ressourcen automatisch freigeben.

Aber für all diese Verbesserungen braucht es natürlich ein wenig Wissen und diverse Tools, mit denen sich vor allem das Laufzeitverhalten parallel ablaufender Anwendungen untersuchen lässt. Hiefür bietet Apple seinen Entwicklern beispielsweise ein Debugger-Tool, das in die Entwicklerumgebung Xcode integriert ist. Oder das Analysetool “Instruments”, mit dem man zur Laufzeit in GCD hineingucken kann, um mögliche Schwachstellen oder Programmierfehler aufzudecken. Damit soll es sogar möglich sein, Warteschlangen zu untersuchen, und das auf Code-Ebene.

Dann bin ich schon mal sehr gespannt auf den Freitag und was Apple zu Snow Leopard zu erzählen hat. Und mit etwas Glück erfahre ich vom anwesenden Produktmanager mehr über GCD und ob es Dinge wie Dead Locks und andere fiese Sachen zur Laufzeit entdeckt. Mal sehen.

Lesetipp: Für alle, die jetzt mehr Lust bekommen haben auf Grand Central Dispatch, hat Apple ein PDF online gestellt, das schon mal die wichtigsten Fragen beantwortet. Das werde ich mir beizeiten genauer ansehen. So, stay tuned …

Am gestrigen dritten und letzten Tag der Game Developers Conference 2009 hatten wir noch ein richtiges “Wow”-Erlebnis. Und zwar am Crytek-Stand, wo wir Zeuge einer Präsentation wurden, in der es um die brandneue Entwicklungsumgebung von Crytek geht. Diese versteht sich als Komplementärprodukt zur CryEngine 3, die sich ja noch im Beta-Status befindet. Was wir von dem CryEngine-Backend sehen konnten, war mehr als beeindruckend.

So wird es möglich sein, ein neues Spiel für alle drei Plattformen – also PC, PlayStation und XBox – gleichzeitig zu entwickeln. Dabei lassen sich sämtliche Veränderungen an einem Level in Echtzeit testen – auf allen drei Plattformen. Das wird natürlich die notwendigen Entwicklungszeiten drastisch reduzieren. Das geht sogar so weit, dass Veränderungen an einem Gamelevel beim Ausfall einer der drei Plattformen nach deren Neustart automatisch aktualisiert werden – ein weiterer wesentlicher Vorteil für Spieleentwickler.

Aber auch die Integration von weiteren Tools wie Photoshop in die Crytek’sche Entwicklerumgebung hat es in sich: So lassen sich beispielsweise bestehende Texturen per einfachem Drag’n'Drop in die Bildbearbeitungssoftware kopieren, verändern und wieder per Mausklick in den Gamelevel übernehmen. Wirklich sehr trivial. Aber auch das Erstellen neuer Objekte wir Inseln, Felsen etc. geschieht schnell und einfach per Maus. Es war wohl noch nie leichter, Game-Designer zu sein …

Auf die CryEngine-3-Spiele kann man sich also wirklich freuen, wenngleich die Unterschiede zur CryEngine 2 nicht so dramatisch ausfallen werden. Außerdem müssen wir uns noch ein wenig gedulden, bis die nächste CryEngine ansteht. Denn das kann locker 2012 werden, wie wir von Cevat Yetil (CEO von Crytek) erfahren haben.

Anlässlich der Game Developers Conference 2009 in Köln betrat Steve Hughes von Intel die Bühne, um über ein Tool zu sprechen, von dem hier schon öfter die Rede war: Intel Graphics Performance Analyzer. Mithilfe dieses kleinen Software-Werkzeugs können Spieleentwickler wie Sega ihre Titel so optimieren, dass sie nicht nur auf Desktop-PCs mit diskreter Grafikkarte vernünftig laufen, sondern auch auf Rechnern mit integriertem Grafikchip.

Um dabei eine optimale Balance aus flüssigem Gameplay und möglichst detail- und effektreichen Bildern zu garantieren, ermittelt Intel GPA vorhandene Hotspots eines Spieletitels wie in Empire: Total War. Hierfür haben die Software-Spezialisten der Sega Tech Group im Auftrag von Sega das komplette Spiel zu Testzwecken zweigeteilt: “Kampagnen” und “Schlachten”. Innerhalb dieser zwei Segmente wurden dann mithilfe des Intel GPA interessante Dinge identifiziert.

Dazu gehörte beispielsweise das Rendern der Küstenlinie, was eine Menge an Rechenzeit beansprucht. Zuviel für ein System mit integrierter Grafik. Die Lösung war dann recht simpel: Shader-Befehle wurden vereinfacht, sodass die GPU weniger zu rechnen hat, ohne dass die Szenerie ihren Reiz verliert. Ähnlich verfuhren die Software-Entwickler in Sachen Regenschauer, die das Spiel auf Notebooks erheblich ausbremsten. So entschlossen sich die Sega-Ingenieure dazu, die einzelnen Regentropfen mit einer Textur zu überziehen, anstatt diese mithilfe eines aufwendigen Shaders berechnen zu lassen.

Nach seiner Präsentation hat sich Steve dann noch ein wenig Zeit genommen, um uns Intel Graphics Performance Analyzer in Aktion zu zeigen. Sehr sehenswert!

• Da die parallel arbeitenden Warteschlangen mit der Version 2.2 sowohl begrenzt (bounded) als auch unbegrenzt (unbounded) arbeiten, sollten Programmierer möglichst die begrenzten Warteschlangen benutzen.

• Da sich die Rückgabewerte der Vektor-Funktionen grow_by, grow_to_at_least und push_back geändert haben, ist der Funktionsaufruf ein wenig einfacher geworden. So wird aus std::copy(begin, end, x.begin()+x.grow_by(end-begin)); jetzt std::copy(begin, end, x.grow_by(end-begin));

• In Intel TBB 2.2 ist auto_partitioner() als Standard gesetzt und löst damit simple_partitioner() ab.

• Der Begriff der Task-Tiefe spielt in TBB 2.2 keine Rolle mehr. Daher sind depth_type und die Methoden depth(), set_depth() und add_to_depth().

Mehr Infos und weitere Codebeispiele sind im angegebenen Blogbeitrag erhältlich.

Das soll vor allem Software-Entwicklern die Möglichkeit geben, Intel TBB bei der Programmierung und Optimierung von Multithread-Sourcecode von Anfang an einsetzen zu können. So umfasst beispielsweise die Unreal Engine von Epic Games ab sofort eine kommerzielle Lizenz der Intel TBB, Autodesk stellt in Maya Intel TBB standardmäßig zur Verfügung.

Neben diesen Neuerungen gibt es weitere Dinge, die hinsichtlich mehr Leistung optimiert wurden:

• Der Taks-Scheduler wurde erheblich überarbeitet, sodass optimierte Anwendungen auf Multicore-Plattformen besser skalieren. Dazu gehören eine automatische Initialisierung bei paralleler Ausführung bestimmter Codeabschnitte und das Zusammenfassen mehrerer Tasks zu einer Gruppe.

• Der Memory Allocator wurde ebenfalls verbessert, was den standardmäßigen Allocator des Betriebssystems ersetzen kann. Folge: bessere Skalierbarkeit der vorhandenen Speicherressourcen und weniger Datenkollisionen.

• Darüber hinaus gibt es neue und verbesserte Konstrukte. Neu sind parallel_invoke and parallel_for_each, mit deren Hilfe sich parallele Konstrukte noch einfacher erstellen lassen. Zudem wurde das Erstellen der häufig benutzten parallel_for-Konstrukts vereinfacht.

Ach ja: Für ein besseres Verständnis, was es mit den optimierten Lambda-Funktionen auf sich hat, empfehle ich zwei Blogposts (Nummer 1 und Nummer 2) des Kollegen Reinders, in denen er sehr anschaulich erklärt, was es bringt und was sich dadurch ändert.

Cilk is a general-purpose programming language designed for multithreaded parallel computing.

Hey, dachte ich, das ist doch ein prima Thema für mein Blog. Also, dann schnell mal geguckt, was Cilk und Intel gemein haben (neben der Absicht, die parallele Programmierung unter C/C++ zu vereinfachen:

If you’ve visited cilk.com today, you see that the Cilk engineering team has joined Intel.

Das heißt also, Intel und Cilk machen jetzt gemeinsame Sache?! Sieht ganz danach aus. Denn wie sagt James zusammenfassend:

Cilk technology will complement other methods we have had great success with – including OpenMP and Intel Threading Building Blocks.

Aha, das bedeutet, dass Cilk++ eine prima Ergänzung zu den Intel-Tools wie Parallel Studio oder Intel TBB bedeutet? Soll wohl so sein. Doch was steckt hinter Cilk++ und was sind die Merkmale dieser Programmiersprache?

Nun, ähnlich wie bei OpenMP gibt es sogenannte Keywords (bei OpenMP heißen diese “Pragmas”), mit deren Hilfe sich ein seriell programmierter Quellcodeabschnitt in ein parallel ablaufendes Konstrukt verwandelt. Ein beliebtes und oft verwendetes Beispiel ist die rekursive Berechnung von Fibonacci-Zahlen, mit deren Hilfe der Mathematiker 1202 n. Chr. das Wachstum einer Kaninchenpopulation beschreiben wollte:

cilk int fib (int n)
02 {
03 if (n < 2) return n;
04 else
05 {
06 int x, y;
07
08 x = spawn fib (n-1);
09 y = spawn fib (n-2);
10
11 sync;
12
13 return (x+y);
14 }
15 }

Die entscheidenden Schlüsselwörter lauten spawn (Zeile 8 und 9) und sync (Zeile 11). Dies Keywords sorgen dafür, dass die Funktion parallel auf zwei oder mehreren Prozessorkernen ausgeführt wird. Den Rest übernimmt die Runtime von Cilk++, die sich um das Erstellen von Threads kümmert, um das Synchronisieren derselben und um das richtige Beenden der parallel laufenden Threads. Dies ist auch der große Unterschied zu OpenMP.

Darüber hinaus verfügt Cilk++ über zwei weitere Keywords: inlet und abort. Inlets sind einfache Funktionen innerhalb einer Cilk-Prozedur, die den Rückgabewert einer parallelisierten Funktion übergeben. Der Witz an Inlets ist deren atomare Struktur: Soll heißen, dass diese Funktionen vom Scheduler nicht synchronisiert werden müssen, was die Fehleranfälligkeit einer derart parallelisierten Funktion minimiert. Abort beendet diese inlet-Funktionen.

Cilk gibt es übrigens schon ziemlich lange: Enstanden am ehrwürdigen MIT Laboratory for Computer Science, wurde es bereits 1994 zum ersten Mal erwähnt. Kein Wunder also, dass sich Intel der Dienste von Cilk Arts bedient und Cilk++ ins eigene Portfolio aufnehmen wird, um beispielsweise Parallel Studio weiter voranzubringen.

Ach ja: Wer mehr Insider-Wissen zu Cilk haben will. sollte auf jeden Fall deren Multicore-Blog besuchen.

Wer nun denkt, “man kann leider nicht alles haben”, liegt falsch. Wie das Video mit Gas Powered Games zeigt, konnten die Entwickler von Demigod mithilfe der Toolsuite Graphics Performance Analyzers (GPA) von Intel eine Leistungssteigerung von etwa 30 Prozent erzielen – ohne dabei auf wesentliche 3D-Effekte verzichten zu müssen. Denn gerade beim Rendern produzierten sie einen echten Flaschenhals, den sie mit GPA entdecken konnten. Dabei ging es vor allem um einen ganz speziellen Effekt auf einem einzigen Level, der sich als Störenfried entpuppte – und der für das Laptop-Gaming eliminiert wurde. Lieber ein Schimmern oder Gleißen weniger als 10 oder 20 Bilder pro Sekunde.

Das Gute aus GPG-Sicht war auch die Tatsache, dass sich dieser Effekt recht einfach entfernen ließ und dazu nicht die komplette Shader-Einheit umgeschrieben werden musste, was den Entwicklern natürlich eine Menge Zeit erspart hat. Auch dabei hat die Toolsammlung geholfen, da sie grafisch basiert arbeitet und sich somit Hotspots und andere Flaschenhälse ohne größeren Aufwand identifizieren lassen. Auf diesem Weg konnten die Männer rund um Chef-Entwickler Bart Kijanka auch einen nervigen Blur-Effekt-Fehler aufspüren, der zwar schön aussieht (der Effekt, nicht der Fehler), aber gerade auf Laptops mit integrierter Grafik eine Menge an Performance-Einbußen mit sich brachte. Also, weg damit!

Beide Probleme wurden übrigens in einem einzigen Durchlauf mit den Grafiktools gefunden, was die Möglichkeiten der GPA unterstreicht. Klar, dass Bart sehr euphorisch die Zusammenarbeit mit Intel und den Support preist, der Gas Powered Games zuteil wurde. Wer sich also angesprochen fühlt, die Graphics Performance Analyzers mal selbst auszuprobieren, wird entweder (kostenlos) Mitglied des Entwicklerprogramms “Visual Adrenaline” oder berappt 300 Dollar für die Toolsuite.

Dieses Jahr geht es nach Köln, die Veranstaltung heißt GDC’09, aber die Fragen werden wieder wichtig sein. Und die Themen natürlich auch. Eine der technischen Sessions wird sich beispielsweise mit der Frage beschäftigen, warum der Spieletitel “Empire: Total War” sogar auf Notebooks mit integriertem Grafikchip spielbar ist, ohne dass dabei auf die visuellen Effekte und den Spielspaß verzichtet werden muss.

Ich kann es ja schon mal ein wenig vorweg nehmen: Es wird um das Intel-Tool Graphics Performance Analyzer gehen, mit dessen Hilfe die Entwickler von Creative Assembly resp. Sega ihr 3D-Epos Laptop-tauglich gemacht haben. Soll heißen, es wurden Bottlenecks und andere Dinge aufgespürt, die dazu führen, dass das 3D-Abenteuer unter normalen Umständen auf einem Notebook mit Intel-Grafikchip nur unzureichend laufen würde. Mit dem Analysetool lassen sich diese Flaschenhälse identifizieren und eliminieren.

Wer jetzt auf den Geschmack gekommen ist und “Empire: Total War” in Aktion sehen will, sollte sich schon mal im Kalender den 18. August rot markieren. Dann gibt es mehr Infos zu den Optimierungsarbeiten am Sega-Spieletitel. Und die 3D-Schlachten werden in Köln sicherlich auch zu sehen sein.

Die Parallel Debugger Extension weist folgende Hauptmerkmale auf:

• Das Aufspüren von Data Sharing, also der gemeinsame Datenzugriff mehrerer Threads auf eine identische Speicherzelle. Hierfür sind die Schalter /debug:parallel und /Qopenmp am Anfang des Quellcodes notwendig, die dem Compiler mitteilen, den Sourcecode entsprechend zu kompilieren.

• Mit der Funktion Re-entrant Function Call Detection lässt sich die Anwendung anhalten, sobald zwei Threads gleichzeitig auf ein und dieselbe Funktion zugreifen.

• Der direkte Zugriff auf sämtliche SSE-Register führt zu einem verbesserten Verständnis, was bei der Programmausführung auf Prozessorebene stattfindet.

• Falls beim Kompilieren des Quellcodes der Schalter /Qopenmp gesetzt wurde, hat man per Debugger Extension Zugriff auf sämtliche Datenstrukturen wie Tasks, wartende Tasks, Task-Locks etc.

• Eine mithilfe von OpenMP-Pragmas parallelisierte Anwendung lässt sich mit wenigen Mausklicks als sequentielles Programm ausführen und debuggen, was die Fehlersuche eindeutiger macht: Haben sich die Bugs beim Parallelisieren eingeschlichen oder basieren sie auf grundsätzlichen Schwächen im Programmdesign?

Dies ist übrigens nur einer kleiner Auschnitt der Funktionsvielfalt der Parallel Debugger Extension. Falls ihr mehr dazu wissen wollt, empfehle ich den Download des 29-seitigen PDF-Dokuments, das sehr detailliert auf die Debugger-Erweiterung des Parallel Composer eingeht.

• Intel Parallel Inspector ist aus dem Thread Checker entstanden und jetzt ein Teil der Entwicklersuite Parallel Studio. Damit ist klar, dass sich Parallel Inspector nur in Verbindung mit Visual Studio 2005 oder 2008 unter Windows nutzen lässt. Thread Checker hingegen ist ein Stand-Alone-Tool, das man sowohl unter Windows als auch mit Linux einsetzen kann.

• Beide Werkzeuge eignen sich für das Aufspüren von möglichen Data Races und Dead Locks, vor allem für parallel programmierte Anwendungen. Darüber hinaus spürt Parallel Inspector mögliche Speicherprobleme auf.

• Parallel Inspector hat natürlich von den Fehlern des Thread Checkers gelernt, ist daher schneller einsetzbar, generiert bei der Analyse der Anwendung weniger Overhead und sorgt für skalierbare Tests, ohne dass die Anwendung vorher serialisiert werden muss.

• Thread Checker basiert auf einem Lizenzmodell, das den Einsatz des Tools auf mehreren Rechnern erlaubt, aber immer nur auf einem PC zur selben Zeit. Zudem bietet Intel für den Checker unbegrenzten Premier-Support und für die Dauer eines Jahres kostenlose Produkt-Updates.

Das absolute Highlight des GUI-basierten Linux-Debuggers von Intel ist die Möglichkeit, einzelne Breakpoints zu setzen, zu speichern und bei Bedarf das so markierte Projekt wieder aufzurufen. Das ist vor allem dann hilfreich, wenn sich die Umgebungsentwicklung mal verabschieden sollte oder man andere Dinge zwischendurch zu tun hat, bevor man sich wieder dem Debuggen zuwendet. Ein Breakpoint wird dank der grafischen Bedieneroberfläche per doppeltem Mausklick erzeugt – und genauso schnell wieder entfernt. Das macht das Testen von C/C++ und Fortran-Projekten wirklich sehr komfortabel.

Aber auch das Testen parallel programmierter Projekte unter Linux geschieht mit dem Debugger von Intel recht überzeugend. So kann man in Echtzeit eine komplette Anwendung (oder Teile davon) auf mögliche Data Races hin untersuchen. Genau genommen identifiziert der Debugger Szenarien, in denen es zu gemeinsamen Datenzugriffen kommen kann, was vor allem das konkurrierende Speichern zweier Threads betrifft. Der Programmierer oder Entwickler muss dann selbst entscheiden, ob dieser parallele Schreibzugriff gewollt ist oder im schlimmsten Fall einen Absturz der Anwendung zur Folge haben kann.

Das Aufspüren von potenziellen Data Races kann übrigens ohne Breakpoint erfolgen. In diesem Fall muss man im Debugger die Option “Stop on Event” einstellen, und schon hält das Programm genau an der Stelle an, wo der “Crash” erfolgt. Zur schnellen Fehlerfindung wird die verursachende Stelle im Quellcode angezeigt. Dies können einzelne Adressen sein, aber auch vollständige Funktionen im Sourcecode.

Neben der klassischen Programmierung unterstützt der Linux-Debugger von Intel auch OpenMP, was immer öfter bei der parallelen Programmierung eingesetzt wird. In diesem Fall geht es vor allem um ein Überwachen des Threadpools: Sind sämtliche Threads, die sich dort befinden, thread-sicher und wenn nicht, an welchen Stellen kann es zu Data Races kommen?

Ach ja: Ein wichtiger Tipp beim parallelen Programmieren lautet: Denke von Anfang an parallel, entwerfe parallel, programmiere aber zuerst seriell. Dies stellt sicher, dass der sequentielle Quellcode fehlerfrei läuft und sich anschließend die parallelen Konstrukte einbauen lassen – beispielsweise mithilfe von OpenMP. In diesem Fall müssen für das serielle Debuggen nicht sämtliche OpenMP-Pragmas entfernt oder deaktiviert werden. Der Debugger führt nämlich die parallelen Konstrukte auf einem einzigen Thread aus, so als ob es sich um eine Single-Core-Maschine handeln würde.

Zu den Präsentierenden gehörte Dr. Carsten Bange vom Marktforschungsunternehmen BARC, der eine Menge interessanter Fakten in Sachen Datenaufkommen der Gegenwart und Zukunft zu erzählen hatte. So generierte laut Bange Wal Mart im Jahr 1992 gerade mal ein Terabyte Daten, 2007 waren es schon 1.000 Terabyte – Tendenz stark steigend.

Die Kurzdarstellungen der Herren Michael Kempke von IMS Healthcare und Frank Stoll von Quelle gewährten ebenso interessante Einblicke in ihre Zusammenarbeit mit Exasol und den Einsatz von deren Datenbankanwendung EXASolution. So analysiert IMS beispielsweise mithilfe von EXASolution 960 Millionen Rezeptdaten innerhalb von schlappen 5 bis 12 Minuten.

Eines hatten die drei Referenzkunden also gemein: EXASolution hat ihnen bei der Lösung ihrer Probleme wirklich weitergeholfen. Denn neben der wohl recht unproblematischen Implementierung (parallel zur bestehenden Infrastruktur) geht es bei der Exasol-Lösung vor allem um Tempo.

So ähnelten die genannten Zahlen einander frappierend: Wartete man mit der vorherigen DB-Lösung mehrere Stunden auf ein brauchbares Ergebnis, nimmt dieselbe Operation dank EXASolution nur wenige Minuten in Anspruch. Ein erheblicher Wettbewerbsvorteil, in der Tat. Damit rückt die immer wichtiger werdende Echtzeit-Verarbeitung von großen Datenbeständen ein gutes Stück näher.

Woher aber kommt diese Überlegenheit von EXASolution gegenüber den Mitbewerbern? Nun, da ist zum einen die sehr gute Skalierbarkeit zu nennen. Der Datenbanklösung ist nämlich völlig egal, ob sie auf einem oder Dutzenden von Clustern läuft. Damit sind der jeweiligen Anwendung so gut wie keine Grenzen gesetzt.

Zudem hat Exasol schon früh darauf geachtet, dass die Datenbankabfragen nicht nur innerhalb eines Clusters parallel ausgeführt werden, sondern dass EXASolution auch das Multicore-Potenzial heutiger und zukünftiger Prozessoren optimal ausnutzt. Hierfür haben die Exasol-Entwickler sogar zu (erlaubten) Hilfsmitteln wie VTune gegriffen, mit dessen Hilfe Hotspots und kritische Abschnitte einer Anwendung gefunden und eliminiert werden können.

All diese Anstregungen haben sich offensichtlich gelohnt: Denn neben zufriedenen Kunden (zu denen übrigens auch Xing gehört) erreicht EXASolution beim anerkannten HPC-Benchmark TPC-H in allen Bereichen erstaunliche Bestwerte, hinter denen sich die Konkurrenz eigentlich nur beschämt verstecken kann. Und das Preis-Leistungs-Verhältnis der Datenbanklösung kann sich ebenfalls sehen lassen.

Außerdem wird Aaron wohl das ein oder andere über Larrabee erzählen, die zukünftige GPCPU-Lösung von Intel, mit der sich sehr parallel und sehr schnell nicht nur 3D-Berechnungen, sondern auch ganz allgemeine Aufgaben durchführen lassen.

Deshalb: Kommet doch alle um 15 Uhr in den Raum Quantm auf dem GamesCamp Munich 2009.

Um Cinema 4D multicore-tauglich zu machen, unternimmt Maxon schon seit vielen Jahren größte Anstrengungen. Das geschieht bereits seit Mitte der 90er Jahre, lange bevor die die ersten Prozessoren mit Hyperthreading auf den Markt kamen. Schon damals galt die Parallelprogrammierung als eine nicht ganz triviale Disziplin, da man vor allem die gemeinsamen Speicherzugriffe und die daraus resultierenden Probleme wie Dead Locks und Data Races in den Griff bekommen musste. Mit Erfolg, wie man an Cinema 4D gut sehen kann.

Doch was hat Maxon alles im Laufe der Jahre getan, damit die Anwendungen auf einem Multicore-System optimal skalieren? Dazu hat Tilo Kühn, Senior Software Developer bei Maxon, eine recht einfache Erklärung parat: Man muss als Entwickler vor allem dafür sorgen, dass die Datenstrukturen von Anfang an so angelegt werden, dass beim parallelen Ausführen der Anwendung die Anzahl der Synchronisation so gering wie möglich ausfällt und es nicht zu Data Races oder ähnlichen Verklemmungen kommen kann. Denn jede Datensynchronisation bedeutet einen Mehraufwand, der den Programmablauf unnötig stört und behindert.

Das gilt zumindest für Systeme mit bis zu acht Prozessorkernen. Darüber hinaus weiß Maxon bereits heute, dass de Programmiertechniken weiter verbessert werden müssen, um in Zukunft auch auf Systemen zu skalieren, die mehr als acht Cores bieten. Allerdings sind die Leute bei Maxon schon eine ganze Weile an dem Thema dran, sodass möglicherweise mit der nächsten Version von Cinema 4D ein neues Framework zum Einsatz kommen wird. Das Ganze wird dann wohl auf Basis des Intel-C++-Compilers Version 11.1 geschehen.

Interessant ist übrigens auch die Aufwandseinschätzung, was das Parallelisieren von Schleifen betrifft, wie sie beim Rendern von 3D-Gebilden häufig angewandt werden: So benötigt man für das Umstellen von sequenziellen auf parallele For-Schleifen mit Bordmitteln (APIs, Pthreads) rund einen Tag, mithilfe von OpenMP-Pragmas ist dieselbe Arbeit innerhalb von gut einer Stunde erledigt – zumindest für einen ersten aussagekräftigen Test. Daher setzt Maxon bei der Anwendungsentwicklung an dedizierten Stellen auf OpenMP.

Daneben verwendet Maxon schon seit langem VTune Performance Analyzer, um bestimmte Aspekte des Programmablaufs besser verstehen zu können. Hier kommt unter anderem der CallGraph zum Einsatz, um die Zusammenhänge des objektorientierten Programmierens transparenter und damit greifbarer zu machen. VTune würde bei Maxon sogar noch öfter genutzt, wenn der Overhead, der beim Sampling des Sourcecodes entsteht, geringer wäre. Wie gut, dass sich Intel dieser Herausforderung in Form des Parallel Studios und des darin enthaltenen Parallel Inspectors erfolgreich gestellt hat. Der Inspector basiert nämlich auf VTune, allerdings in einer schlanken Fassung, die deutlich weniger Overhead produziert.

Ebenfalls zum Einsatz kommt bei Maxon der Thread Profiler. Was Tilo Kühn an dem Tool besonders mag ist die sehr anschauliche, grafische Darstellung der zeitbasierten Thread-Abhängigkeiten. Auf diesem Weg lassen sich ganz spezielle Codeabschnitte untersuchen, indem man dem Profiler mitteilt, an welcher Stelle mehrere Theads parallel ausgeführt werden. Damit lassen sich relativ einfach mögliche Verklemmungen während des Programmablaufs aufspüren. Aber auch gegenseitige Abhängigkeiten von Threads kann man mit dem Thread Checker grafisch darstellen.

Das verlangt doch geradezu nach einem Einsatz des Parallel Studio bei Maxon, oder?! Was auch passieren wird, wie mir Tilo Kühn glaubhaft versicherte. Na dann: Go parallel!

Für aufmerksame Leser des Software Dev Blogs werden sich nicht sonderlich viele Neuigkeiten aus dem Beitrag ableiten lassen, aber in seiner Abgeschlossenheit trägt der Artikel doch sehr zum Verständnis von Parallel Studio bei. Zudem handelt es sich um ein PDF-Dokument, das sich sogar ausdrucken lässt. Für die analogen Zeitgenossen unter uns.

Der Artikel umfasst drei Seiten und geht recht detailliert auf die einzelnen Komponenten ein, also Parallel Composer, Parallel Inspector und Parallel Amplifier. Lustigerweise beginnt der Beitrag mit dem Parallel Advisor. Dieses Tool wird erst in der nächsten Version zum Parallel Studio gehören, kann allerdings heute schon als eine Art Techdemo kostenlos ausprobiert werden.

Schön an dem Parallel-Studio-Beitrag sind die praxisorientierten Einblicke, die man anhand der eingefügten Bilder gewinnen kann. Schade ist allerdings, dass diese teilweise recht klein geraten sind. Und ein, zwei Codebeispiele hätten dem Artikel zu ein wenig mehr Pfiff verholfen. Na ja, beim nächsten Mal dann, ok?!

Klar, dass es dabei vor allem um Visual Studio 2010 samt .NET 4 gehen wird, aber natürlich auch um Parallel Studio mit Parallel Composer, Parallel Inspector und Parallel Amplifier. Ich bin schon sehr gespannt, wer alles dort zugegen sein wird, um sich höchstpersönlich die Infos aus erster Hand zu holen.

Am übernächsten Wochenende folgt dann das GameCamp Munich 2009, auf dem ich ebenfalls anwesend sein werde, um vor Ort zu bloggen, zu netzwerken und das ein oder andere Video zu drehen. Doch ich werde nicht allein sein: Intel wird sich als Sponsor betätigen und wohl am Sonntag eine eigene Session zum Thema Visual Computing und Multicore abhalten. Das wird bestimmt sehr spannend. Außerdem wird der Kollege hoffentlich einen Demo-PC dabei haben, mit dessen Hilfe er das Thema Multicore-Programmierung für 3D-Spiele anschaulich vorführen kann.

Ach ja: Das GameCamp Munich 2009 findet in Unterschleißheim bei Microsoft statt, die ihre Räumlichkeiten für die Konferenz zur Verfügung stellen. Und was ich so gehört habe, sind noch Plätze frei. Also, worauf wartet ihr noch mit der Anmeldung?!

• 75 Prozent aller teilnehmenden Entwickler konnten bereits nach 15 Minuten sinnvolle und nachvollziehbare Ergebnisse produzieren.

• Ebenfalls 75 Prozent haben Parallel Studio als “empfehlenswert” eingestuft (8 von 10 Sternen im Mittel).

• 86 Prozent der teilnehmenden Betatester glauben, dass die Threading-Methoden von Parallel Studio (OpenMP, Intel TBB, etc.) für ihre Zwecke völlig ausreichend sind.

• 71 Prozent der Betatest-Entwickler konnten einen Geschwindigkeitszuwachs bei ihren Anwendungen messen, und das nur wegen des Umstiegs auf den integrierten Intel-C++-Compiler, der natürlich äußerst multithreading-tauglich ist.

Und es gibt sogar schon erste Referenzgeschichten, die den Einsatz von Parallel Studio in ein bestehendes Projekt verdeutlichen sollen. Dazu gehört beispielsweise die in Paris ansässige Firma Open Cascade, die die gleichnamige Opensource-Software entwickelt hat und für Kunden in deren Anwendungen integriert. Mit Open Cascade lassen sich komplexe und sehr aufwendige 3D-Modelle erstellen, wie sie beim Produktdesign, in der Simulationstechnik und in anderen Bereichen verwendet werden.

Da die Berechnung und grafische Umsetzung solcher 3D-Modelle sehr rechenintensiv und Open Cascade zudem C++-basiert ist, kam für mehr Leistung und schnellere Berechnungen Parallel Studio zum Einsatz. Schnell zeigte sich, dass der Parallel Amplifier typische Hotspots mit wenig Aufwand entdecken konnte. So ließ sich beispielsweise die Berechnung von geometrischen Flächen drastisch beschleunigen, indem dem betreffenden Algorithmus ein eigener Thread zugewiesen werden konnte, der bei Bedarf immer wieder parallel ausgeführt werden kann.

Aber auch der Parallel Inspector half dabei, Open Cascade zu verbessern und schneller zu machen. Das führte insgesamt zu einer doppelt so schnellen Rechengeschwindigkeit und einer Reduzierung von Speicherproblemen (Meomory Leaks).

Dabei geht es im Gegensatz zur dynamischen Fehlersuche um das Aufspüren potenzieller Fehler im Sourcecode selbst und nicht um Bugs, die erst zur Laufzeit auftreten. Damit lassen sich unter anderem Speicherprobleme, fehlerhafte Variablendefinitionen, Fehler bei den OpenMP-Deklarationen und vieles mehr aufspüren.

Und, interessiert? Dann solltet ihr ganz schnell auf die Intel-Webinar-Seite gehen und euch flugs für das Online-Seminar anmelden. Es findet nämlich in gut vier Stunden statt.

Zunächst einmal: Mit dem Parallel Advisor stellt Intel ein Tool zur Verfügung, das Entwicklern und Programmierern dabei helfen soll, Parallelisierungspotenzial ihrer Anwendungen zu identifizieren. Und das nicht per Trial-and-Error, sondern mit erprobten Messverfahren, die diejenigen Codeabschnitte ermitteln, bei denen sich das Multithreaden am ehesten lohnt. Hierfür unterstützt Parallel Advisor Lite diverse Ansätze:

Flexible Handhabung: Der Advisor kann zu jedem beliebigen Zeitpunkt der Anwendungsentwicklung laufen. Entscheidend ist nur, dass Microsoft Visual Studio 2005 oder 2008 samt einer C++-Entwicklungsumgebung und Parallel Studio zum Einsatz kommen.

Eingebaute Skalierbarkeit: Der Parallel Advisor sorgt für skalierende Anwendungen, die auf den kommenden Intel-Plattformen “mitwachsen”.

Einsatz von Industriestandards: Dank des Einsatzes von OpenMP und anderer Techniken orientiert sich Parallel Studio und damit auch der Parallel Advisor an anerkannten Industriestandards, was die Software-Entwicklung mit diesen Tools zukunftssicher macht.

Vereinfachte Parallelprogrammierung: Der Parallel Advisor erfordert laut Intel relativ wenig Vorwissen in Sachen Parallelprogrammierung. Gleichzeitig soll sich das Erfolgserlebnis recht schnell einstellen.

Bekannte Programmiermethoden: Parallel Advisor unterstützt sowohl Daten- als auch Aufgabenparallelismus.

Um eine sequenziell programmierte Software-Anwendung effizient und ohne größere Kopfschmerzen zu parallelisieren, sind mithilfe des Parallel Advisors folgende Schritte notwendig:

• Die laufende Anwendung wird auf mögliche parallelisierbare Abschnitte hin untersucht. Hierbei handelt es sich um eine Hotspot-Analyse, die potenzielle Konstrukte wie Schleifen für die Parallelisierung identifiziert.

• In Frage kommende Abschnitte der Anwendung werden entsprechend markiert, sodass ein späteres Einfügen von Parallelkonstrukten mithilfe von OpenMP, Intel TBB und Co. möglichst einfach vonstatten geht.

• Anschließend werden diejenigen Programmabschnitte identifiziert, die Dead Locks und ähnliche Probleme verursachen können.

• Es werden an denjenigen Sourcecode-Stellen entsprechende Programmierzeilen eingefügt, die dabei helfen sollen, Datenprobleme mithilfe passender Konstrukte zu beseitigen.

• Nach ausführlichen Tests des seriellen Quellcodes werden abschließend alle markierten Stellen durch Multithread-Konstrukte ersetzt. Das macht aus dem sequenziell programmierten Software-Titel eine parallel ablaufende Anwendung, die die vorhandenen Multicore-Ressourcen hoffentlich optimal nutzt.

Zugegeben, ganz unvorbereitet bin ich nicht auf das gestrige Ereignis. So findet Parallel Studio auf dem Software Dev Blog schon seit dem 24. Oktober statt. Damals habe ich das Parallelisierungstool in einem Nebensatz zum ersten Mal erwähnt. Die erste echte Erwähnung fand das C++-Werkzeug am vorletzten Tag des Oktobers 2008, und zwar in Vorbereitung auf die Microsoft-Entwicklerkonferenz TechEd im schönen Barcelona. Tja, und einen Tag später habe ich dann ein wenig mehr verraten über Parallel Studio und habe es ziemlich kühn “Multicore-Turbo” genannt.

Seitdem folgten diverse Beiträge rund um das Entwicklertool, das sich nahtlos in Visual Studio 2005 und 2008 von Microsoft einbetten lässt. Highlights waren zweifellos zwei Interviews mit Steve Teixeira und Dariusz Parys von Microsoft, ein Vierteiler zu Parallel Studio mit ersten Einblicken in die Toolsuite (Teil 1, Teil 2, Teil 3 und Teil 4) und die Liveberichterstattung von der Intel Software Conference 2009 aus Salzburg.

Unerwähnt sollten aber auch nicht die zahlreichen Onlineseminare bleiben, die Intel rund um Parallel Studio im Angebot hatte bzw. noch hat.

Ach ja: Teil des Parallel Studio wird ein viertes Tool sein, der Parallel Advisor. Mit diesem Parallel-Studio-Add-On soll Software-Entwicklern dabei geholfen werden, ihre Anwendungen schneller, effizienter und mit weniger Aufwand zu parallelisieren. Da der Advisor erst mit der nächsten Version des Parallel Studio Teil der Suite wird, stellt Intel registrierten Mitgliedern des ISN den Advisor Lite als TechPreview auf Whatif.com zum kostenlosen Download zur Verfügung. Damit alle interessierten Entwickler und Programmierer schon mal damit herumspielen und ihr Feedback an Intel weiterleiten können. Mehr Infos zum Advisor gibt es morgen auf diesem Sender!

Und was hat das alles mit Software-Entwicklung zu tun? Nun, für Spieleentwickler ergibt sich daraus ein wichtiger Aspekt: Wie kann ich dafür sorgen, dass meine Spiele auf den verschiedenen Plattformen gleichermaßen gut laufen, also auf diskreten Grafikkarten genauso wie auf integrierten Grafikchips. Und genau an diesem Punkt kommt Graphics Performance Analyzers von Intel zum Einsatz. Mit dieser Toolsuite können Spieleprogrammierer recht schnell und unkompliziert herausfinden, an welchen Schrauben sie drehen müssen, um ihre Spieletitel für sämtliche Computerplattformen zu optimieren.

Graphics Performance Analyzers (GPA) umfasst drei Einzeltools: den System Analyzer, das Frame Capture Tool und den Frame Analyzer. Damit lassen sich verborgene Bottlenecks und andere Hemmschuhe aufspüren, die das Spiel davon abhalten, auf einem Notebook mit integrierter Grafikkarte vernünftig zu laufen. Toll an GPA ist die Tatsache, dass die Analyse auf einem separaten System läuft, während sich das zu untersuchende Spiel auf einem eigenen Laptop befindet. Beide Rechner werden mit einem Netzwerkkabel verbunden und tauschen auf diesem Weg die notwendigen Daten aus.

Derzeit unterstützt GPA lediglich die Intel-G45- und Mobile-Intel-GM45-Express-Chipsatz-Familien und untersucht nur DirectX-basierte Spiele. Aber wie man Intel kennt, werden wohl weitere Chipsätze in Zukunft folgen.

An die Toolsuite kommt man auf zwei Wegen heran: Entweder registriert man sich für das kostenlose Visual Adrenaline Program, das vom Intel Software Network betrieben wird. Oder man begibt sich in den Onlineshop Intel Business Exchange und kauft die Tools für rund 300 US-Dollar.

Video-Tipp: In einem Video-Interview live von der GDC’09 in San Francisco beantwortet Aaron Davies von Intel zahlreiche GPA-Fragen.

• Eine kleine Einführung in Sachen VS 2010 und .NET 4 von der Intel Software Conference 2009.

• Microsoft und Intel veranstalten im Juni 2009 rund um das Thema parallele Programmierung diverse Seminare, in denen es auch um VS2010 und .NET 4 gehen wird.

• Ein Interview mit Dariusz Parys von Microsoft zum Thema VS 2010 und dessen Multithread-Fähigkeiten.

• Ein Dreiteiler in Sachen Multicore-Programmierung im .NET (4)-Umfeld (Teil 1, Teil 2, Teil 3).

• Ein Workshop live von der Multicore-Konferenz anlässlich des prio.powerday. Thema: “Parallele Programmierung unter .NET 3.5″, was erahnen lässt, was später unter .NET 4 alles möglich sein wird.

• Die Open-Source-Datenbank MySQL konnte dank der Intel C++ Compiler um 27 bis 42 Prozent schneller gemacht werden. Und zwar sowohl für Pentium-4- als auch Itanium-2-Prozessoren.

• Mithilfe des Intel-Fortran-Compilers gelang es der australischen Swinburne-Universität für Astrophysik, ihre HPC-basierten Anwendungen auf dem zugehörigen Supercomputer nochmals um 22 bis 31 Prozent zu beschleunigen.

• Die Datenbankanwendungen von Oracle laufen sowohl unter Linux als auch unter Windows schneller, da beide Versionen dank der Multicore-Optimierungen der entsprechenden Compiler noch mehr aus der Hardware herausholen.

• Das Erstellen von MP3-Songs mithilfe der Kodierungssoftware Musicmatch Jukebox geschieht dank des Intel C++ Compilers um 37 Prozent schneller als zuvor. Hierzu hat die Profiling-Software VTune Performance Analyzer allerdings auch einen Teil beigetragen.

Neben diesen compiler-basierten Verbesserungen hilft VTune immer mehr Software-Anbietern, ihre Anwendungen für Intel-Prozessoren zu optimieren. Dazu gehört bespielsweise Kaspersky Lab, das seine Antiviren-Software mithilfe des Intel-Tools verbessern konnte. Ebenso konnte Abaqus Inc. dank VTune seiner Simulationssoftware neues Leben einhauchen.

Wer mehr wissen will zu den einzelnen Erfolgsgeschichten, begebe sich auf die zugehörige Webseite. Dort finden sich auch sämtliche Fallstudien in PDF-Form zum Download.

Am heutigen Dienstag ist um 18:00 Uhr MESZ ein Online-Seminar dran, das sich an C-/C++-Programmierer richtet, die mithilfe von Parallel Studio und Visual Studio ihren Softwareprodukten paralleles Leben einhauchen wollen. Dabei geht es um die Fragen, an welchen Stellen, in welchem Umfang und mit welchen Mitteln Quellcode multithread-tauglich gemacht werden kann, damit er auf Multicore-Systemen optimal skaliert. Ach ja: Es wird empfohlen, ergänzend am Webinar mit dem Titel  “Identify and Address Threading Opportunities” teilzunehmen, das für den 12. Mai anberaumt ist.

Also, dann nix wie zur Anmeldeseite hingesurft, schnell registrieren und für das Webinar eintragen. Dann könnt ihr heute Abend Punkt 18:00 Uhr am PC mehr zu Parallel Studio erfahren.

• Intel C++ Compiler 11.0
• Intel VTune Performance Analyzer 9.1
• Intel Thread Checker 3.1
• Intel Thread Profiler 3.1
• Intel Threading Building Blocks 2.1
• Intel Integrated Performance Primitives 6.0

und über vieles andere mehr.

Das Praktische an all diesen Entwicklerwerkzeugen: Ihr könnt sie völlig kostenlos testen, und das 30 Tage lang. Und zwar nicht nur die Linux- und Mac-OS-Varianten, sondern auch die komplette Windows-Suite. Daneben gibt es auch Linux-Tools, die gar nichts kosten und keiner zeitlichen Beschränkung unterliegen. Einzige Bedingung hierfür: Die Linux-Anwendungen, die damit geschrieben werden, dürfen nicht zu kommerziellen Zwecken eingesetzt oder gar verkauft werden.

Und falls ihr euch den kostenlosen Intel-Support während des Testmonats nicht entgehen lassen wollt, müsst ihr euch einmal einen Premier Support Account zulegen. Und schon könnt ihr Intel mit euren Fragen zutexten, bis die DSL-Leitung glüht.

Ach ja: Bevor ihr die Tools auf euren Rechner packt, solltet ihr einen Blick auf die Softwarevoraussetzungen werfen. Damit ihr die Werkzeuge auch ohne Probleme einsetzen könnt.

Ein sehr schöner Einstieg in das Thema Tuning ist folgendes Zitat: “Ich weiß, wie ich vier Pferde dazu bringe, einen Wagen zu ziehen. Wie aber geht das mit 1024 Hühnern?” Das ist eine wirklich passende Analogie zur Optimierungsarbeit beim parallelen Programmieren. Denn es gibt so viele Fallen, in die man beim Multithreading tappen kann: nicht-skalierender Code, Deadlocks oder Data Races zur Laufzeit und vieles mehr.

Dafür gibt es den Parallel Amplifier, der Flaschenhälse findet, die Skalierbarkeit der Anwendung ermittelt und mehr. Es hilft also Entwicklern und Programmierern, die parallele Struktur und das parallele Verhalten ihrer Anwendung besser zu verstehen.

Wie schon der Composer und Inspector, integriert sich Parallel Amplifier in Visual Studio und findet folgende Probleme:

• Wo verbraucht meine Anwendung die meiste Zeit?

• Wann gehen die Prozessoren in den Idle-Modus?

• Wo gibt es ungewollte Wartezeiten?

Sobald Amplifier die möglichen Fehler gefunden hat, lassen sich die entsprechenden Quellcode-Stellen per Mausklick öffnen und auf die Fehler hin überprüfen.

Parallel Amplifier findet aber auch Unter- und Überschäftigung der vorhandenen Prozesorkerne, zeigt also sehr anschaulich, in welchem Umfang die Ressourcen genutzt werden.

Praktisch ist auch die Vergleichsfunktion, die es ermöglicht, die Ergebnisse zweier Durchläufe grafisch darstellen zu lassen. Also vor und nach der Optimierung und deren Auswirkung auf die Ausnutzung der Ressourcen.

Jetzt folgt eine Livedemo, die den Amplifier präsentiert. Und auch hier muss ich leider sagen, dass sich das geschriebene Wort nicht dafür eignet, das Gesehehene vernünftig zu beschreiben. Aber ich versuche auch in diesem Fall, etwas Anschauliches nachzuliefern. Interessant dabei ist die Tatsache, dass der Amplifier die EXE-Datei zur Laufzeit analysiert und anschließend innerhalb von Visual Studio die Ergebnisse darstellt. Das macht das Aufspüren der betreffenden Quellcodestellen ziemlich einfach.

Überraschend war übrigens der Wechsel des Compilers, um in diesem Anwendungsfall eine spezielle Bibliothek nutzen zu können. Die Laufzeit reduzierte sich von 15 Sekunden auf unter eine Sekunde. Dies ist auf den Intel-C++-Compiler zurückzuführen, der diese Bibliothek bereithält und die Laufzeit dramatisch verringert.

Los geht das Ganze um 9 Uhr kalifornischer Zeit (PDT), also um 18:00 unserer Sommerzeit. Hoffen wir mal, dass das so stimmt, da bisher die Webinars bereits um 17:00 MEZ losgingen. Kann also nicht schaden, schon mal um fünf Uhr vorbeizuschauen. Und zwar per Mausklick auf diesen Link.

Ach ja: Wer den Inspector schon mal live und in Farbe sehen will, sollte sich das dazu passende Video ansehen, das die Kollegen während der GDC’09 gedreht haben.

Interessant an dem Video sind mehrere Sachen: Zum einen kann man gut sehen, wie sich der Testrechner konfigurieren lässt. Zum anderen kann man sogar kompilierte Dateien testen, die in C# programmiert worden sind. Da soll noch einer sagen, in die Executables der Microsoft Concurrency Runtime könne man nicht “hineinschauen”. Concurrency Checker kann. Und wie.

Denn wie das Video sehr anschaulich zeigt, sieht man nicht nur die Skalierbarkeit des gestesteten Tools, sondern kann auch die einzelnen Threads ansehen und wie diese auf die vorhandenen Prozessorkerne verteilt werden. Wenn man jetzt noch weiß, welche Programmabschnitte der Anwendung in welche Threads zerlegt werden, kann man die weniger gut performenden Programmabschnitte entsprechend “tunen” und damit bessere Multithread-Ergebnisse erzielen.

Und das Tollste daran: Concurrency Checker kostet keinen Cent. Also los, macht doch mal die Probe aufs Exempel und überprüft mithilfe des Tools, wie gut euer selbst Programmiertes auf Intel-Plattformen läuft. Die Ergebisse dürft ihr natürlich hier als Kommentar hinterlassen – oder auch nicht.

Damit ihr euch schon mal einen ersten lebendigen Eindruck vom Parallel Conposer verschaffen könnt, ist die Teilnahme an dem kostenlosen Webinar sicherlich eine gute Idee. Also, hierher klicken, anmelden und um 17:00 MEZ einwählen. Viel Spaß dabei!

Mit dabei ist natürlich auch Intel, das in diesem Segment eine maßgebliche Rolle spielt – und nicht erst seit Bekanntwerden der geplanten GPCPU-Technik Larrabee. Denn vor allem die integrierten Grafikchips ermöglichen immer realistischere 3D-Bilder – und das sogar auf Notebooks. Gerade dort sind spezielle Features wie eine dauerhafte In-Game-Akkuanzeige wichtig, aber auch so Spezialitäten wie Ad-hoc-Netze für Multiplayer-Spiele erfordern ein wenig Know-how, um diese in Spieletitel zu implementieren.

Richtig “insight”-mäßig wird es gleich am heutigen Dienstag (24.3.): Dann geht es nämlich um das Thema “Multithreading von 3D-Spielen”. Zwischen 10 und 18 Uhr lokaler Zeit zeigen Paul Lindberg, Brad Werth und Orion Granatir von Intel acht Stunden lang, wie man parallel denken muss, wie man ein neues Multithread-System in ein bestehendes Framework implementiert, wie man Datenabhängigkeiten findet und wie man diese mit den passenden Tools eliminiert.

Aber auch der Mittwoch (25.3.) hat es in sich: Es geht um neue Intel-Tools, mit deren Hilfe Spiele noch einfacher, schneller und effizienter optimiert werden können für den Einsatz auf Multicore-Systemen, Notebooks und Co. Darüber hinaus gibt es exklusive Tipps & Tricks rund um integrierte Grafikchips, einen Workshop zum Thema “Echtzeit-Effekte in 3D-Welten”, viele Infos zum Multithreaden von Künstlicher Intelligenz in Spieletiteln und einiges mehr.

Und was der Mittwoch kann, hat der Donnerstag schon lange drauf: Wie optimiert man Spieletitel mithilfe der Intel Threading Building Blocks? Welche Hardware-Anforderungen erfüllen die aktuellen Intel-Plattformen und was muss ich bei der Spieleentwicklung berücksichtigen?  Und welche Tools stehen mir zur Verfügung, um neue Spiele schnell und effizient zu entwickeln?

Der Freitag schließlich hält ein echtes Schmankerl für alle Larrabee-Neugierigen parat: In zwei separaten Workshops erfährt man alles über den neuen Befehlssatz LRBni und wie sich dieser für die Rastererisierung und die SIMD-Programmierung eignet. Abgerundet wird das Ganze mithilfe eines Beispiels aus der Spieleindustrie, und zwar anhand der brandneuen Middleware Substance Air von Allegorithmic, mit der eine neue Ära des Oberflächendesigns (Texturing Design) eingeläutet werden soll. Spieleentwickler, die in Zukunft auf Substance Air setzen, werden dabei nämlich von der vollen Multicore-Power profitieren, da die Middleware im höchsten Maße multihreaded ist.

Der Morgen beginnt ganz gemütlich mit ein paar einleitenden Worten des Gastgebers. Anschließend macht sich James Reinders, Oberchef der Software Developer Group bei Intel, ein paar Gedanken zu der Frage, wie es Programmierer und Entwickler schaffen können, ihren Anwendungen paralleles Leben einzuhauchen. Denn in Zeiten fallender Taktraten pro CPU und steigender Prozessorkerne pro System wird es immer wichtiger, sich mit dem Thema Multithreading und Multicore-Optimierung zu beschäftigen. Wie dies am Beispiel Parallel Studio funktioniert, verrät er auch schon mal ein wenig.

Nach der ersten kurzen Pause geht es dann interessant weiter. Eric Vernié, einer der führenden Software-Evangelisten bei Microsoft, wird sich mit Visual Studio 2010 und .NET 4.0 beschäftigen und anhand dieser zukünftigen Entwicklungsumgebung zeigen, wie sich Redmond das Thema Parallelprogrammierung vorstellt. Wer wissen will, wie Erics Vortrag in etwa aussehen könnte, sollte sich das Interview zu Gemüte führen, das ich mit Dariusz Parys anlässlich der OOP 2009 geführt und hier veröffentlicht habe.

Anschließend wird es praxisorientierter: Charly Lippoth, Chief Technology and Strategy Officer der Nero AG, plaudert aus dem Nähkästchen und wird den Anwesenden verraten, wie die Zusammenarbeit zwischen Intel und Nero funktioniert und wie es möglich ist, dass die Multimedia-Suite Nero 9 derart gut auf Multicore-Plattformen wie dem Core i7 von Intel skaliert. Dass so etwas nicht automatisch geschieht, dürfte klar sein. Klar ist auch, dass Nero unter anderem VTune und die aktuellen Intel Compiler eingesetzt hat, um ein Optimum bei der Multicore-Programmierung zu erzielen. Ach ja, und Beta-Tester von Parallel Studio ist Nero auch.

Heinz Bast, mit dem ich selbst schon sprechen durfte, verschafft dann einen – alles andere als oberflächlichen – Einblick in den Parallel Composer. Mit diesem Tool soll es selbst weniger erfahrenen Parallelprogrammierern gelingen, Multithread-Quellcode zu erzeugen und damit bestehenden oder neuen Software-Titeln den Turbo zu verpassen. Heinz wird im Detail über OpenMP, Intel TBB, Intel Parallel Debugger Extension und einiges mehr reden.

Was Heinz kann, beherrscht Levent Akyil natürlich genauso: technische Zusammenhänge so aufzubereiten, dass diese auch von weniger erfahrenen Zuhörern im Kopf zu einer Geschichte zusammengesetzt werden können. Levent bekommt zu diesem Zweck sogar zwei Sessions zur Verfügung gestellt, in denen er sowohl über den Parallel Inspector als auch den Parallel Amplifier reden wird.

Der Inspector überprüft parallelisierten Quellcode und findet kleinere und größere Bugs zur Laufzeit, was mit herkömmlichen Testtools kaum oder nur mit großem Aufwand möglich ist. Der Amplifier hingegen ist das Tuning-Tool des Parallel Studio, mit dem sich Hotspots aufspüren lassen, der Anteil des Multithread-Codes erhöhen lässt und überflüssige Wartezeiten gefunden werden können.

Nach so viel “tough stuff” können wir dann ab vier Uhr wieder etwas verschnaufen und erneut den Worten von James Reinders lauschen, wenn er kurzzeitig die Gegenwart verlässt, um über die Zukunft der Parallelprogrammierung zu reden. Dabei geht es natürlich um die Weiterentwicklung des Parallel Studio dank des Parallel Advisor, eines fast schon revolutionär anmutenden Tools, das Entwicklern bei der Parallelisierung helfen soll. Und was es mit “Ct” auf sich hat, werden wir ebenfalls lernen.

Tja, und zu all diesen Themen werde ich am 22. April live und exklusiv bloggen. Also, am besten schon mal den RSS-Feed abonnieren oder mir via Twitter folgen.

Der wesentliche Tag ist der Dienstag (21.4.), an dem es eine Menge Infos rund um Multithreading, Multicore-Tools und mehr geben wird. Die Agenda sieht unter anderem Vorträge vor von James Reinders (Intel), Eric Vernié (Microsoft), Charly Lippoth (Nero), Heinz Bast (Intel) und Levent Akyil (Intel). Dabei geht es vor allem um Parallel Studio, die brandneue Toolsuite von Intel, mit deren Hilfe in Zukunft Software-Parallelität einfacher implementiert werden kann.

Was im Detail alles auf der Entwicklerkonferenz passieren wird, gibt es demnächst hier nachzulesen. Versprochen!

Ach ja: Ich werde natürlich nicht nur zu meinem Vergnügen nach Salzburg reisen. So will und werde ich den ganzen Tag von der Intel Software Conference 2009 live und exklusiv auf diesem Sender bloggen. So wahr mir Wifi helfe …

Warum ich das alles erzähle? Nun, ich hatte gestern die exklusive Gelegenheit, mit Noel Borthwick ein ausführliches Telefonat zu führen. Noel ist CTO von Cakewalk, also der führende technische Kopf des Unternehmens. So gesehen hat Noel eine ganze Menge über Sonar und dessen Multithread-Fähigkeiten zu erzählen.

Zunächst einmal gab es ein wenig Geschichtliches. So erfuhr ich, dass Cakewalk Pro Audio etwa 1993/94 entstanden ist und damals schon multithread-fähig war. Ok, natürlich nur auf einer Multisocket-Plattform mit zwei parallel geschalteten Prozessoren, mit deren Hilfe es möglich war, die komplette Bedieneroberfläche auf einen separaten Thread auszulagern und die Audio Engine auf die zweite CPU. Das war sicherlich nicht sonderlich effektiv, zeigt aber, das sich Cakewalk schon seit mehr als 15 Jahren mit dem Thema Multithreading beschäftigt – und das sehr erfolgreich, wie die Firmenhistorie zeigt.

Im Jahr 2001 vollzog Cakewalk dann den Namenswechsel: Aus Cakewalk Pro Audio wurde Sonar und damit ein skalierendes Produkt, das auf Basis einer komplett neu entwickelten Audio Engine die Möglichkeiten des damals aufkommenden Software-Multithreadings erheblich besser ausnutzen konnte als sein Vorgänger. Hierfür war neben dem Redesign der Software auch ein eigener Task Scheduler notwendig, der in Sachen Funktionsumfang dem Task Scheduler der Intel TBB ähnelt. Für eine optimale Skalierung werden also die vorhandenen Ressourcen (Kerne) ermittelt und anhand dessen die anstehenden Aufgaben (Tasks) intern in Threads umgewandelt und zur Laufzeit dynamisch auf die vorhandenen Prozessorkerne verteilt.

Um diese Software-Skalierung zu perfektionieren, arbeitet Cakewalk kontinuierlich an Sonar. So kommt beispielsweise permanent der VTune Performance Analyzer zum Einsatz, um ausgeglichene Kernel Workloads zu erzielen. Aber auch Treiberprobleme lassen sich auf diesem Weg ermitteln und beheben. Dies führt insgesamt zu geringeren Ladezeiten, was sich vor allem bei großen Musikprojekten positiv bemerkbar macht, die sich aus einer Vielzahl von Tracks, Plugins und anderen Objekten zusammensetzen. Zudem lassen sich mit VTune recht einfach Cache Misses und andere unschöne Dinge ausfindig machen.

Der Thread Checker ist für Cakewalk immer wieder von Vorteil, wenn es zum Beispiel um das Aufspüren von Synchronisationsproblemen von Threads geht, die ja meist erst zur Laufzeit auftauchen. So half Thread Checker Cakewalk beim Eliminieren eines Priority Inversion-Problems, das sich eines Tages in Sonar 8 bemerkbar machte: Aufgrund einer falschen Thread-Priorisierung verhielt sich das Tool an manchen Stellen völlig anders als erwartet, was natürlich mit unzufriedenen Kunden endete. Dank Thread Checker konnte das Laufzeitproblem behoben werden und alle waren wieder glücklich.

Surftipp: Wenn ihr mal sehen wollt, wie sich Multithreading in Sonar 8 bemerkbar macht, solltet ihr unbedingt diese Webseite ansurfen. Dort gibt es sehr aufschlussreiche Benchmarks, die Sonar 8 mit dessen Vorgänger Sonar 7 vergleichen. Vor allem beim Sonar-eigenen Benchmark kamen Steigerungsraten von bis zu 240 Prozent heraus. Ich sag mal, da haben die Cakewalk-Entwickler multithreading-seitig ganze Arbeit geleistet!

Mein erster Gedanke zur neuen Webseite rund um die parallele Programmierung: sehr aufgeräumt. Denn die Seite besteht lediglich aus einer Handvoll von Verweisen auf Informationen, die sich mit den unterschiedlichen Aspekten des Parallel Computing befassen.

Dazu gehören nützliche Infos zu Parallel Studio, die nur einen Mausklick entfernt sind. Dort könnt ihr euch über die einzelnen Tools der Suite informieren (Composer, Inspector und Amplifier). Ihr könnt euch aber auch für das Beta-Programm eintragen oder sogar bei QT software oder der SOS Software Service GmbH bereits heute ein Paket von Parallel Studio vorbestellen. Oder seht euch einfach mal das Video an, dass Intel mit dem Parallel-Guru James Reinders gedreht hat.

Aber die Webseite hält auch eine Menge an Informationen für alle HPC-Enthusiasten (High Performance Computing) bereit. Hier geht es primär um die ganzen anderen Tools, die Intel für das Multithreaden und Optimieren von Hochleistungsanwendungen bietet. Die Rede ist also von Compilern, Threading Building Blocks, Integrated Performance Primitives, Math Kernel Library, Thread Checker und anderen Tools.

Übrigens: All diese Produkte können ausprobiert und auch gekauft werden. Und einige dieser Software-Pakete kann man sogar kostenlos nutzen, solange man damit keine kommerzielle Anwendungen baut.

So erfährt der interessierte Entwickler in Video Nummer 1 alles über die zur Disposition stehenden Fachbegriffe und wie diese in den fünf anderen Videoclips verwendet werden. Es geht also um so Dinge wie Multicores, Manycores, Threads und andere Begrifflichkeiten, mit denen man sich zunächst beschäftigen sollte, um die anderen vier Videos besser zu verstehen.

Video Nummer 2 verschafft einen guten Überblick, was das in der Beta-Phase befindliche Entwicklertool Parallel Studio alles leistet und welche Funktionen es umfasst. Also Inspector, Composer und Advisor. Wobei dieser derzeit noch nicht Teil von Parallel Studio ist. Kommt aber noch …

Übrigens: Die ins Deutsche transkribierten Trainingsvideos gibt es voraussichtlich ab nächster Woche auf zdnet.de!

Der Thread Profiler ist ein Analysetool, mit dem sich Schwachstellen in parallelisierten Anwendungen grafisch darstellen lassen. Hierzu ist kein Quellcode notwendig, da der Thread Profiler das ausführbare Programm, also die Exe-Datei, untersucht. Dabei können folgende Dinge aufgespürt werden:

• Unter- und überbeschäftigte Ressourcen werden grafisch dargestellt. Damit kann der Programmierer sofort sehen, an welchen Stellen das Programm auf der Multicore-Plattform optimal, ein wenig oder gar nicht skaliert.

• Der Programmablauf wird visualisiert. Es lässt sich auf diesem Weg also feststellen, wo die kritischen Pfade sind, welche Abschnitte der Anwendung sequenziell ausgeführt werden und an welchen Stellen die einzelnen Threads aktiv oder inaktiv waren bzw. wann sie warten mussten.

• Es werden beide Zustände des Programmablaufs grafisch dargestellt: die Ausführung der parallelen Threads und der chronologische Ablauf der Software.

• Mittels Doppelklick auf eine bestimmte Stelle innerhalb des Ablaufplans der Anwendung verzweigt der Entwickler genau an die Stelle innerhalb des Quellcodes, an der die Probleme auftauchen. Damit kann er die kritischen Abschnitte im Sourcecode verifizieren und mit viel Know-how und Erfahrung die Fehler eliminieren.

• Synchronisationsprobleme zwischen den einzelnen Threads lassen sich lokalisieren und beheben. Aber auch ein ungleichgewichtiges Verteilen auf die vorhandenen Threads bzw. Prozessorkerne spürt der Thread Profiler auf.

• Eine OpenMP-basierte Testmethode ermöglicht das Überprüfen unterschiedlicher Programmdesigns, um somit den besten Optimierungsansatz herauszufinden.

Den Thread Profiler gibt es in einer Standalone-Variante oder als Teil des VTune Performance Analyzer. Darüber hinaus fügt er sich nahtlos in Visual Studio 2003, 2005 und 2008 ein und ist für C++ sowie Fortan-Projekte unter Windows konzipiert. Zudem ist er kompatibel mit den Threading Building Blocks und OpenMP. Den Thread Profiler gibt es 30 Tage lang zu Evaluierungszwecken, und das natürlich gratis. Allerdings muss man sich einmalig registrieren, um in diesem Genuss zu kommen.

• Es stellt die Anzahl der vorhandenen CPU-Ressourcen fest, also Prozessoren und Prozessorkerne (und sogar virtuelle CPUs).
• Es stellt fest, wie viele Threads jeweils parallel ausgeführt werden und wie lange dies insgesamt dauert.
• Es berechnet den prozentualen Anteil des parallelisierten Quellcodes.

Der Concurrency Checker kann aber noch mehr: So stellt er fest, ob die Multithread-Anwendung anhand der vorhandenen Prozessorkerne skaliert, diese also vollständig ausnutzt. Dies geschieht übrigens zur Laufzeit der Software. Schön an dem Tool ist aber auch die Tatsache, dass es nicht erst aufwendig installiert werden muss und damit sofort zur Verfügung steht. Und zwar mittels einer grafischen Bedieneroberfläche oder im simplen Zeileneditormodus.

Das Werkzeug kann aber auch auch zu Vergleichszwecken eingesetzt werden: Zunächst lässt man sein serielles Programm einmal mit dem Tool durchlaufen, um so die benötigte Laufzeit herauszufinden. Nach der Parallelisierung geschieht das Ganze noch einmal, womit man einen guten Indikator dafür erhält, wie gut das Multithreaden der Anwendung geklappt hat.

Was der Concurrency Checker allerdings nicht kann ist zweierlei: Es gibt keine Hinweise darauf, welche Stellen der sequenziell programmierten Anwendung das höchste Parallelisierungspotenzial aufweisen. Und zum anderen lassen sich Hotspots und andere Probleme der parallelisierten Software mit dem Tool nicht herausfinden. Wie gut aber, dass es hierfür Werkzeuge wie den VTune Performance Analyzer und den Thread Checker gibt.

Ach ja: Den Concurrency Checker bekommt ihr auf dieser Webseite, und das gratis!

Zunächst einmal: OpenMP liegt in der Version 3.0 vor und stellt eine standardisierte Programmierungsmethode dar. In Sachen Komplexität bewegt sie sich zwischen den herkömmlichen Threads – also API-Threads, PThreads oder WinThreads – und den höher entwickelten Intel TBB oder der geplanten Parallel Pattern Library (PPL), die von Microsoft kommen wird.

Daraus ergeben sich zwei wesentliche Aspekte: OpenMP ist weitaus einfacher zu verstehen, zu implementieren und zu testen als die Low-Level-Threads, bei denen sich der Programmierer um viele Dinge selbst kümmern muss, was das Ganze natürlich extrem fehleranfällig macht.

Die Kehrseite von OpenMP ergibt sich aus der geringeren Komplexität: Nicht alle Programmieraufgaben lassen sich mit OpenMP erledigen, was den Entwickler natürlich ein wenig einschränkt. OpenMP versteht sich vor allem sehr gut auf das Parallelisieren von rechenintensiven Schleifenkonstrukten.

Doch für welche Projekte eignet sich OpenMP am besten? Nun, hier ist vor allem der inkrementelle Ansatz zu nennen. Hierbei wird Stück für Stück ein bestehendes seriell programmiertes Programm mit einem geeigneten Tool wie dem VTune Performance Analyzer auf sein Parallelisierungspotenzial hin untersucht, um so schrittweise sequenziellen Programmcode in parallelen zu überführen. Das Gute dabei ist die Tatsache, dass es einen Masterthread gibt, der die sequenzielle Programmausführung steuert.

Sobald die Anwendung an einen Punkt kommt, wo es simultan werden kann, verzweigt die Ausführung in eine feste Anzahl von Threads. Wenn dieser Programmteil beendet ist, verzweigt die Anwendung wieder in den sequenziellen Masterthread. Ein weiterer Vorteil von OpenMP ist die Möglichkeit, bei der Programmausführung die parallelen Code-Abschnitte per “Schalter” zu deaktivieren, um somit aufgetretene Fehler im Seriellmodus zu debuggen. Das erleichtert das Auffinden vorhandener Bugs ungemein.

Die Implementierung von parallelem Code auf OpenMP-Basis ist übrigens recht einfach: Hierzu stehen dem Programmierer bestimmte Derektiven (Pragmas), die OpenMP-Bibliothek und Umgebungsvariablen zur Verfügung. Bei der Überführung von seriellem in parallelen Programmcode müssen dann nur ein paar Programmzeilen eingefügt werden. Das ist unter anderem die Bibliothek omp.h, die passende Anzahl von Threads sowie einer Umgebungsvariablen und die Pragma-Anweisung selbst, die sich um das Parallelisieren des vormals seriellen Programmcodes kümmert.

Das nachfolgende Beispiel berechnet mithilfe einer Integralfunktion die Kreiszahl Pi. Die blau eingefärbten Programmzeilen sind die hinzugefügten OpenMP-Variablen sowie das zugehörige Pragma. Übrigens: Nur der in den geschweiften Klammern stehende Programmteil wird parallel ausgeführt. In diesem Fall also die Formel, die iterativ Pi ermittelt.

Schon seinerzeit habe ich dagegen gesprochen, da sehr wohl Software-Werkzeuge existieren wie die Integrated Performance Primitives (IPP), die vor allem Entwickler von Multimedia-Software bei ihrer Arbeit unterstützen sollen. So basieren zahlreiche MP3- und AAC-Encoder/-Decoder auf Teilen der IPP-Bibliotheken, in denen übrigens viele Mannjahre Entwicklungsarbeit stecken.

Mit den IPP lassen sich einzelne Funktionen für das Encoden von Audio- und Videostreams mehr oder weniger per Drag & Drop für eigene Anwendungen nutzen, die dann bestimmte Aufgaben hochparallelisiert ausführen – ohne dass der Programmierer sich darüber Gedanken machen muss, wie dies funktioniert. Bekannte Beispiele hierfür sind H.264-, MPEG-4- und AAC-basierte Encoder.

Aber auch im medizinischen Bereich für die rechenintensive Auswertung von Ultraschallbildern kommen IPP-Bibliotheken zum Einsatz. Damit lassen sich hochkomplexe 3D-Bilder deutlich schneller analysieren, da die vorhandenen Prozessoren simultan die Berechnungen durchführen können. Somit spart der Einsatz der IPP im günstigsten Fall drei bis vier Mannjahre Entwicklungszeit, die das Programmieren solcher Parallel-Bibliotheken resp. der zugehörigen Anwendung in Anspruch nähmen.

Ein weiteres bekanntes Beispiel ist auch der Winzip-Codec, der mithilfe von IPP parallelisiert wurde und damit eine erheblich beschleunigte Kompression und Dekompression von Daten auf Multicore-Systemen ermöglicht. Hierbei kümmert sich IPP auf Basis von OpenMP (also mithilfe spezieller Pragma-Konstrukte) sogar um die Skalierung von Winzip, indem die einzelnen Threads möglichst gleichmäßig auf die vorhandenen Prozessorkerne verteilt werden.

Das Tolle an den IPPs sind auch die Anschaffungskosten: Es werden nämlich umgerechnet gerade mal 200 Dollar pro Entwickler fällig, dem für diesen geringen Betrag sämtliche vorgefertigte Funktionen zur Verfügung stehen. Unterstützt werden Window, Linux und Mac OS X, zudem gehört eine 30-Tage-Testversion zum Angebot und für nicht-kommerzielle Linux-Anwendungen kosten die Integrated Performance Primitives keinen einzigen Cent.

Wie ich ja schon berichtet habe, sucht der Parallel Amplifier nach Optimierungspotenzial in Multithread-Anwendungen. Für eine optimale Performance also. Hierfür leistet das Tuningtool eine ganze Menge:

Aufspüren von Hotspots: An welchen Stellen verbrät die Anwendung besonders viel Zeit und was kann ich dagegen tun? Hierzu werden die kritischen Bereiche grafisch dargestellt und können so schneller identifiziert werden. Zudem liefern die Stack-Aufrufe wichtige Infos über das Laufzeitverhalten der Anwendung.

Parallelität verbessern: Wo klappt es mit der Parallelisierung noch nicht so gut und welche Quellcode-Abschnitte könnte man noch weiter simultan schalten? Um diese Fragen beantworten zu können, erhält der Anwendungsentwickler grafisch aufbereitete Hinweise darauf, welche Programmabschnitte die vorhandenen CPU-Ressourcen über- bzw. unterbeanspruchen. Genau an diesen Stellen lässt sich dann der Quellcode tunen.

Wartezeiten finden: Wo muss die Anwendung zu lange warten, weil bestimmte Abhängigkeiten existieren? Wie kann ich diese Hotspots identifizieren und möglichst auflösen? Auch hierfür stellt der Parallel Amplifier die betreffenden Quellcode-Abschnitte grafisch dar und zeigt in Balkenform die Auslastung der Prozessoren an. So lassen sich Idle-Zustände relativ einfach herausfinden.

Eine weitere praktische Eigenschaft des Parallel Amplifier ist dessen Transparenz in Sachen Laufzeitverhalten. So lässt sich jede Funktion, jeder Callaufruf und jede Prozedur bis auf jede einzelne Quellcode-Zeile herunterbrechen und analysieren. Das gibt dem Programmierer ein gutes Gefühl dafür, wo es klemmt und wo er noch mehr machen muss.

Und es lassen sich mehrere Testläufte aufzeichnen und die Ergebnisse miteinander vergleichen. Auch das sorgt im Problemfall für zusätzliche Hinsweise darauf, dass die parallelisierte Anwendung weiter optimiert werden muss – oder sich gar Fehler eingeschlichen haben.

Im Parallel Inspector steckt ein erprobtes Tool, und zwar der Thread Checker. Daher ist der Inspector primär für das Auffinden von Fehlern zuständig, die sich in Multithread-Code eingeschlichen haben. Um dies alles erledigen zu können, beherrscht das Debug-Tool eine Menge Dinge:

• Es entdeckt Speicherprobleme und -fehler, findet also fehlerhafte Speicherzuweisungen und korrupte Speicherdaten, die möglicherweise zu schwerwiegenden Fehlern während der Laufzeit führen würden.

• Die bekannten Threading-Fehler wie Deadlocks und Race Conditions spürt der Inspector zuverlässig auf. Gerade diese nicht-deterministischen Laufzeitprobleme können mit herkömmlichen Debug-Tools kaum oder nur mit größtem Aufwand gefunden werden.

• Der gesamte Multithread-Code wird nach Fehlern durchforstet. Vor allem die zur Laufzeit auftretenden Probleme erkennt der Inspector und führt den Programmierer direkt zu der betroffenenen Stelle. Dabei wird auch der zugehörige Call Stack angezeigt und die betroffenen Speicherstellen. Warnhinweise und Fehlermarkierungen helfen dabei, die aufgetretenen Probleme besser und schneller zu verstehen.

• Das alles findet dank der Integration in Visual Studio unter einer einheitlichen und vertrauten Entwicklerumgebung statt. Damit lassen sich Fehler schneller erkennen, verifizieren und eliminieren. Das Gute daran: Es muss nicht jedesmal ein “Rebuild” des Quellcodes durchgeführt werden.

Mit dem Parallel Inspector lassen sich Multithread-Anwendungen in vielfältiger Weise debuggen. Es  geht allerdings um weit mehr als das bloße Aufspüren von Quellcode-Fehlern:

• Es spielt keine Rolle, welche Programmiermethode eingesetzt wird. Parallel Inspector unterstützt nämlich OpenMP (besser: er basiert darauf), kommt aber auch mit Intel TBB und Windows Threads klar.

• Fehler wie Dead Locks und Race Conditions werden zur Laufzeit gefunden, bevor sie der Kunde findet.

• Das Laufzeitverhalten wird vollständig aufgezeichnet, um so nachträglich und detailliert mögliche Fehler und Probleme innerhalb der parallelisierten Anwendung zu identifizieren.

• Im Gegensatz zu anderen Testtools können schwer auffindbare, nicht-deterministische Fehler mit Parallel Inspector aufgespürt werden.

• Pate des Parallel-Debuggers ist der Thread Checker. Damit bekommt man ein zuverlässiges, weil erprobtes Tool an die Hand zum Debuggen seiner Anwendungen.

• Parallel Inspector fügt sich nahtlos in Visual Studio ein.

Sobald die parallelisierte Anwendung auf Fehler hin überprüft und von denselben befreit werden konnte, schlägt die Stunde des Parallel Amplifier. Mit diesem Optimierungstool lassen sich folgende Dinge anstellen:

• Es bildet die zu optimierenden Quellcode-Bereiche grafisch so ab, dass sich das Skalierungspotenzial mit wenigen Blicken erfassen lässt.

• Kein Trail-and-Error mehr, da das Laufzeitverhalten zuverlässig vermessen und bewertet werden kann.

• Die Optimierungen finden auf einer abstrakten Ebene statt. Damit sind Kenntnisse über die zugrundeliegende Prozessorarchitektur oder des Assemblercodes überflüssig.

• Das Tool ist entstanden auf whatif.intel.com im Dialog zwischen Endanwendern und Intel-Ingenieuren.

• Parallel Inspector basiert auf dem Thread Profiler und VTune Performance Analyzer und steht damit für ein zuverlässiges Tool, das auf rund 15 Jahre Entwicklungsarbeit made by Intel zurückblickt.

• Vollständige Visual-Studio-Integration.

Und, immer noch wissenshungrig in Sachen Parallel Studio?! Dann solltet ihr morgen wieder vorbeischaun. Dann gibt es mehr dazu …

Der erste Teil handelt vom Parallel Composer, der mit einer Reihe nützlicher Tools die Parallelisierung serieller Anwendungen erleichtern soll. Hierfür bietet er

• vereinfachte Multithread-Funktionen, die allesamt auf OpenMP 3.0 basieren und als solche im Hintergrund eingesetzt werden

• Vektorisierungspragmas in Kombination mit den SSE2-/SSE3-/SSSE3- und SSE4-Befehlen

• OpenMP 3.0

• einfache Integration in die Entwicklungsumgebung von Microsoft Visual Studio

• Intel Parallel Debugger Extensions als Plugin für Visual Studio

• Intel Threading Building Blocks

• Lambda-Funktionen (nur C++) für den vereinfachten Austausch mit Intel TBB

• Intel Integrated Performance Primitives

• Unterstützung der Vektorschreibweise (arr[i])

• automatische Parallelisierung von Quellcode

• Diagnosetools, die beim Entwickeln von Multithread-Quellcode helfen

• zahlreiche Multithread-Beispiele mit dem entsprechenden Quellcode

Und am Montag gibt es dann mehr Infos zu Parallel Inspector und Parallel Amplifier ein anschauliches Beispiel, Infos zu OpenMP 3.0 und einiges mehr. Und die zusätzlichen Infos zu OpenMP und Co. gibt es am Dienstag …

10. März 2009: Go-Parallelism! Ease the Onramp for C/C++ Windows Development Hier erfährt man alles Wissenswerte über Parallel Studio aus erster Hand von einem der Parallelexperten aus dem Hause Intel, nämlich James Reinders persönlich. Dieses Webinar ist ein erster, guter Überblick für alle angehenden Parallelentwickler.

17. März 2009: Solve Parallelism with Intel Parallel Studio In seinem Webinar weiht Joe Wolf künftige Multithread-Entwickler in das mathematische Damenproblem (N-Queens) ein und zeigt, wie es sich mithilfe von Parallel Studio lösen lässt. Hierzu sollte man das Entwicklertool am besten schon auf seinem Rechner installiert haben, um die notwendigen Programmierschritte während der Session durchführen zu können.

31. März 2009: Parallel Implementation Methods with Intel Parallel Composer Intel-Mann Ganesh Rao wird eine Menge über Programmiermethoden wie OpenMP und Intel TBB erzählen, die sich in Parallel Studio einbinden und nutzen lassen. Es geht aber auch um multithread-optimierte Bibliotheken wie Intel IPP und Debugger-Tools wie Intel Parallel Debugger Extension und den Parallel Inspector, der ja Teil von Parallel Studio ist.

14. April 2009: Find Errors in Windows C++ Parallel Applications Mitte April geht’s ans Eingemachte: So lernt man anhand entsprechender Beispiele, wie man mithilfe des Tools Parallel Debugger Extension Programmierfehler im C++-Quellcode aufspürt, um diese bereinigen zu können.

28. April 2009: The Good, the Bad, and the Ugly: Improve Parallel Application Quality and Performance Am Anfang war die Konzeption und das Software-Design, und genau darum geht es im Webinar von Eric Moore. Denn nur mit den richtigen Ansätzen lassen sich parallel programmierbare Anwendungen realisieren. Außerdem gibt es diverse Fallbeispiele bekannter (und unbekannter) Software-Entwickler, die Multithread-Tools erfolgreich einsetzen.

12. Mai 2009: Identify and Address Threading Opportunities Caroline Davidson zeigt, wie sich mit Parallel Studio multithread-taugliche Programmabschnitte identifizieren lassen, wie man anhand virtueller Tests mögliche Schwachstellen im Quellcode aufspürt und wie man diese elegant behebt. Darüber hinaus werden OpenMP und Intel TBB ein Thema in Carolines Webinar sein.

26. Mai 2009: Simplifying Parallelism Implementation with Intel Threading Building Blocks In seinem Webinar gewährt Mike D’Mello tiefe Einblicke in die parallele Programmierung mithilfe der Intell TBB, des Parallel Composers und deren Lambda-Funktionen. Daneben geht es um weitere Themen wie Daten- und Aufgabenparallelität, Pipelining und parallele Warteschlangen.

2. Juni 2009: Static Analysis and Intel C++ Compilers Anfang Juni geht es um das Thema Statische Fehlersuche und darum, wie man damit Laufzeitfehler, Ressourcenprobleme und Sicherheitsmängel aufspürt. Und zwar mit den Tools Parallel Composer und Source Checker.

Darüber hinaus gibt es viele weitere Online-Seminare zu Themen rund um Parallel Studio. Hierfür ist allerdings eine bestimmte Anzahl an Anmeldungen notwendig. Also, worauf wartet ihr noch: Seite ansurfen, Webinar(s) mit der Maus aussuchen, registrieren – fertig. Die Anmeldebestätigung  gibt dann weitere Details zum Webinar preis: Uhrzeit (9:00 am PDT, was 18:00 Uhr unserer Zeitrechnung entspricht), Dauer (eine Stunde) und den Link, mit dem man das Online-Training starten kann.

Ach ja: Um herauszufinden, ob die eigene Plattform Intel-Webinar-tauglich ist, sollte man vorher am besten mal die zugehörige Sektion “System Setup & Compatibility Check” aufsuchen. Nicht, dass man kurz vor Trainigsbeginn sein graues Wunder erlebt …

Das Extrahieren dieser Daten geschieht in Echtzeit, also während des laufenden Betriebs. Um eine möglichst reibungslose Archivierung zu garantieren, hat sich die CSP schon sehr früh auf das Multithreaden ihrer Anwendung konzentriert.

Das gesamte Konzept ist also auf parallele Datenverarbeitung ausgelegt. Es findet sogar eine doppelte Parallelisierung statt: Es kommt ein Mini-Cluster zum Einsatz, in dem einzelne Server bestimmte Aufgaben übernehmen. Und innerhalb dieser Server gibt es eine hohe Multithreading-Kultur, die eine skalierende Ausführung der Anwendung sicherstellt.

Chronos ist übrigens vollständig in Java programmiert und findet innerhalb der Java Runtime Environment statt, die standardmäßig mit Java-Threads auskommt. Auf diesem Weg können Java-Anwendungen mithilfe bestimmter Bibliotheken und Klassen parallelisiert werden. Für die komplette Verwaltung sämtlicher Threads hat CSP übrigens einen eigenen Threadmanager entwickelt, der im Hintergrund analog zu den Threading Building Blocks die einzelnen Tasks auf die vorhandenen Prozessoren und Threads verteilt. Für eine bestmögliche Auslastung der Ressourcen.

Wieso können sich die Entwickler von CSP aber so sicher sein, dass Chronos wirklich optimal auf Intel Multicore-Plattformen skaliert? Nun, um das herauszufinden, besorgte man sich in Pilsting-Großköllnbach das kostenlose Tool Concurrency Checker, mit dessen Hilfe festgestellt werden kann, ob eine Anwendung effizient auf Intel Multicore-Plattformen läuft.

Und die Entwickler der CSP GmbH waren ziemlich schnell davon überzeugt, dass der Concurrency Checker das richtige Tool für ihre Zwecke ist. Denn sie waren sehr zufrieden mit der Bedienbarkeit des Programms, da sie für einen ausführlichen Multicore-Test gerade mal einen halben Tag investieren mussten. Danach war den CSP-Programmierern klar, dass sich der Concurrency Checker für ihre Zwecke optimal einsetzen lässt. Und dass Chronos auch das hält, was es verspricht: eine optimale Ausnutzung der vorhandenen Systemressourcen, sprich der Prozessorkerne und Threads.

Tja, und ab sofort steht das komplette Paket Parallel Studio zum Beta-Testen bereit. Das Tool besteht aus den drei Programmteilen Composer, Inspector und Amplifier. Was der Composer kann, muss ich nicht noch mal erklären. Der Inspector untersucht ähnlich wie der Thread Checker parallelisierten Code auf mögliche Fehler hin. Das sind vor allem schlimme Dinge wie Deadlocks und Race Conditions, die sich meist erst zur Laufzeit erkennen geben und mit herkömmlichen Testmethoden oder Debuggern kaum aufspürbar sind.

Der Amplifier schließlich ist für das Finetuning der parallelisierten Anwendung zuständig. So findet er beispielsweise selbstständig seriellen Quellcode, der noch parallelisiert werden könnte. Aber auch Engstellen im Programmablauf, die sich durch die Parallelisierung ergeben haben, stöbert der Amplifier auf.

Um am Betaprogramm von Parallel Studio teilnehmen zu können, sollte man Microsoft Visual Studio 2005 oder 2008 einsetzen (außer Express), in C oder C++ programmieren, und das unter Windows XP, Vista, Windows Server 2003 oder 2008. Mac- und Linux-Anwender bleiben leider (erst mal) außen vor.

Und hier geht es zur Teilnahme am Betaprogramm (für die Anmeldung ist lediglich eine gültige E-Mail-Adresse erforderlich). Viel Spaß beim Testen!

Wichtig erscheint mir auf jeden Fall die Feststellung, dass “in Zukunft [...] Parallelrechner ungefragt und flächendeckend zur Verfügung stehen” werden. Ganz klar, das ist der Trend, und wenn man sich die Roadmap von Intel ansieht, wird schnell klar, dass der Core i7 nur der Anfang der Multicore-Ära ist.

Ebenso wichtig sind die potenziellen Multicore-Anwendungen, die Professor Tichy aufzählt: Dazu gehören natürlich Medienprogramme wie DivX und 3D-Spiele wie Crysis oder Sacred 2 (und Bildbearbeitungstools wie Silver Efex Pro von Nik Software). Aber auch weniger spektakuläre Anwendungen wie Logistikplaner, Tabellenkalkulation, Suchalgorithmen und Sicherheitsüberprüfungen profitieren vom Multithread-Code. Zusammengefasst könnte man mit Tichys Worten sagen:

Diejenigen Firmen, die jetzt die richtigen Anwendungen identifizieren und parallelisieren, werden in Zukunft zu den Gewinnern gehören, zumal Beschleunigung durch Abwarten – das heißt: das Setzen auf weiter steigende Taktfrequenzen – nicht mehr funktioniert.

Aber Professor Tichy weist zu Recht auch darauf hin, dass es große Hemmschwellen seitens der Software-Entwickler gibt, da sie sich durchaus dessen bewusst sind, dass es beim Parallelisieren von Anwendungen so hässliche Dinge wie Race Conditions, Dead Locks, Reihenfolgeprobleme und andere Synchronisationstücken gibt. Außerdem lassen sich bestimmte Fehler einfach nicht reproduzieren, da sie oft erst zur Laufzeit auftreten.

An dieser Stelle gibt es übrigens ein erstes “Hm?!”. Denn Testtools wie der Thread Checker sind durchaus in der Lage, potenzielle Fehler aufzuspüren, bevor ein einziger Betatester oder Endanwender die Software in den Händen hält. Dies ist naturgemäß nicht trivial, aber es sind entsprechende Tools vorhanden.

Ein weiterer wichtiger Punkt in seinem Vortrag hat mit den sequenziellen Algorithmen zu tun, die immer noch zu einem Großteil in existierenden Anwendungen implementiert sind. Die große Herausforderung hierbei ist natürlich das Aufspüren des Parallelisierungspotenzials. Dies lässt sich zum einen mit Tools wie VTune Performance Analyzer oder Thread Profiler erledigen. Zum anderen muss man als Entwickler noch einen wichtigen Schritt weiter gehen: Wie mache ich aus einem sequenziellen ein paralleles Software-Konzept? Und genau an diesem Punkt scheitern immer noch ganz viele.

Jetzt ist übrigens die Gelegenheit gekommen für ein zweites “Hm?!”. Und zwar bezüglich Professor Tichys Aussage, dass es derzeit keine vernünftigen Compiler und Bibliotheken gibt, die ein gewisses Maß an Parallelimus in sich bergen. So stecken beispielsweise im Intel C++-Compiler eine ganze Menge an parallelen Konstrukten und Bibliotheken, die mit wenigen Hangriffen in den Quellcode übernommen werden können. Und Programmiermethoden wie OpenMP erledigen dies sogar automatisch – von den Threading Building Blocks und den multicore-optimierten Bibliotheken ganz zu schweigen.

Aber für Professor Tichy steht außer Frage, dass es hierzulande kluge Köpfe gibt, die durchaus in der Lage sind, mit den richtigen Tools und den richtigen Konzepten die Multicore-Programmierung voranzutreiben und für Anwendungen zu sorgen, die auf 4, 8, 16 oder gar 256 Prozessorkernen skalieren. Und dann wird es auch so kommen, wie Professor Tichy abschließend scheibt:

Bessere Produkte mit intuitiveren Schnittstellen, Sprach- und Videoverarbeitung, mehr Intelligenz und eingehender Modellierung des Nutzers und der Umgebung werden entstehen.

Ach ja: Ich werde mir nächste Woche auf der OOP 2009 den Vortrag von Professor Tichy zum Thema “Herausforderung Mehrkernsysteme” anhören – und dazu mit ihm ein Interview führen. Darauf bin ich schon sehr gespannt!

Das ist sicherlich nicht ganz ernst gemeint, macht aber die Herausforderungen sehr anschaulich, vor der die Entwicklergemeinde stehen wird, sobald Windows 7 auf dem Markt ist und das Programmieren von neuer Software für maximal 256 Cores ansteht. Dann gibt es nämlich nur noch eins: die richtigen Tools kaufen und parallelisieren, was das Zeug hält. Andernfalls wird aus dem Multicore-Riesen ein lahmer Singlecore-Zwerg, der von der sequenziell programmierten Anwendung jämmerlich ausgebremst wird.

Wie gut, dass es hierfür schon einiges gibt und weitere Tools kommen werden. Die Rede ist beispielsweise von den Threading Building Blocks, Thread Checker, Parallel Studio, Visual Studio 2010 und weiteren nützlichen Hilfsmitteln, mit denen die Parallelprogrammierung zwar kein Klacks wird, vieles sich aber vereinfachen lässt.

Ach ja: Für das Problem mit dem unterdimensionierten Windows Taskmanager hat einer der Kommentatoren einen nützlichen Tipp parat: Virtualisierung. Soll heißen, dass sich einfach mehrere Prozessorkerne zu einem virtuellen Prozessor zusammenfassen lassen. Dann passt die Taskmanager-Anzeige auch wieder auf einen 19-Zöller und die Anschaffung eines 30-Zoll-Monitors kann noch einmal verschoben werden …

Was die Pro- und die Standardversion unterscheidet, ist die Möglichkeit, mit dem Pro-Paket eigenen Videocontent zu generieren. Das Standardpaket, das es wie die Pro-Version bis dato nur für Windows gibt, bietet allerdings eine 15-Tage-Testversion mit allen Pro-Funktionen, bis 16 Euro für die Lizenz fällig werden.

Gerade aus Multicore-Sicht ist DivX ein sehr interessantes Stück Software: So werden bis zu acht Prozessorkerne unterstützt und auch der Einsatz des SSE4-Befehlssatzes soll bei der Wiedergabe hochaufgelöster HD-Videos für möglichst ruckelfreie Bilder sorgen. Welche Anstrengungen DivX unternommen hat, um diese gute Skalierbarkeit zu garantieren, wollen wir natürlich genauer wissen und haben mal bei der Pressestelle angefragt.

Sobald es etwas Berichtenswertes gibt, werden wir dies hier veröffentlichen. Versprochen!

We need languages that take full advantage of multicore processing

Genau darum geht es heute. Nicht die Hardware ist der Hemmschuh, sondern die Software, sprich die Programmiersprachen, die derzeit zur Verfügung stehen. Oder wie es der Autor passend formuliert:

Computer evolution, however, is now headed down an entirely new path: instead of simply becoming faster, our computer processors are being conjoined to work together. That new computer architecture requires a serious evolution in computer programming. Without it, we can only scratch the surface of what multicore computing can really do.

Das ist die Kernthese, mit der sich auch dieses Blog immer wieder beschäftigt, denn die Zeiten der GHz-Spirale sind endgültig vorbei, und eine neue Ära des “Parallel Computing” ist angebrochen – sogar im Mainstream-Markt. Denn was die HPC-Gemeinde seit Jahren vormacht, ist auf dem gemeinen Desktop-PC und Notebook jetzt auch möglich, wird nur zu selten richtig eingesetzt.

Eine weitere interessante These stellt der TR-Artikel in Sachen “Umdenken” auf: So wie seinerzeit diverse Software-Entwickler den Trend der objektorientierten Programmierung verschlafen haben, droht heute die Gefahr erneut, da das Schreiben von parallel-orientiertem Sourcecode ebenfalls einen völlig neuen Denkansatz erfordert. Dies betrifft vor allem den gemeinsamen Zugriff auf Daten, dessen Koordinierung in parallelen Systemen bedeutend anspruchsvoller ist als im seriellen Universum.

Aber es gibt laut Paul Tyma, dem Autor des zitierten Beitrags, auch gute Nachrichten: Denn Sprachen wie C++ und Java, die von ihrer Anlage her ja seriell sind, haben große Änderungen erfahren und sind mittlerweile durchaus in der Lage, in Multicore-Umgebungen zu skalieren. Dies machen Tools wie die Intel Threading Building Blocks oder die Intel C++ Compiler deutlich, in denen ein ganze Menge an Multithread-Potenzial steckt. Mit diesen Hilfsmitteln gelingt auch weniger erfahrenen Parallel-Programmierern der Einstieg in die Multicore-Welt. Was die Entwickler allerdings nicht davon abhalten sollte, ihre Software-Projekte in Zukunft akribisch vorzubereiten und über bestimmte Dinge gründlich nachzudenken.

Fazit: Mit den gegebenen Tools könnte der Wechsel von der seriellen zur parallelen Programmierung bald in großem Maßstab gelingen. Oder wie es Paul Tyma zusammenfasst:

With these new languages and programmers’ development of new skills, the acceleration of computing power that we’ve almost come to take for granted will soon be back on track.

Übrigens: Paul war früher bei Google, hat sich dort intensiv mit dem Thema Multicore-Programmierung beschäftigt. Er sollte also wissen, worüber er spricht …

Zunächst einmal helfen unsere fünf Multicore-Regeln, die wir Ende letzten Monats aufgestellt haben. Die wichtigste davon lautet beim Software-Design: Denke parallel! Denn nur so hält man am Schluss eine Anwendung in den Händen, die sich mithilfe der passenden Tools bestmöglich parallelisieren lässt.

Eine beliebte Fehlerquelle ist ein Überangebot an Threads, vor allem dann, wenn Sie diese “manuell” programmieren, so wie im Falle von Pthreads. Daher sollte man durchaus sparsam mit dem Erstellen von Threads umgehen, denn nur eine ausgewogene Balance von parallelem und seriellem Quellcode bringt die erwünschten Leistungsschübe. Oder man bedient sich nützlicher Tools wie Intel TBB, die Threads automatisch generieren.

Ebenfalls sehr wichtig ist die optimale Granularität der zum Einsatz kommenden Locks und Unlocks, denn jedes Sperren und Entsperren von parallelem Programmcode erfordert einen hohen Verwaltungsaufwand. Werden Locks zu lange ausgeführt, können sie andere Threads unnötig blockieren, was die Anwendung insgesamt ausbremst. Und auch die gemeinsam genutzten Speicherressourcen müssen bestmöglich aufeinander abgestimmt sein, denn ein übertriebener Synchronisierungsaufwand macht sich negativ bemerkbar.

Ein weiterer Hemmschuh parallel programmierter Software ist die schlechte Verteilung der notwendigen Tasks auf die vorhandenen Prozessorkerne beziehungsweise Threads. Denn nur wenn Sie diese optimal ausnutzen, indem Sie Leerlaufzeiten einzelner Cores vermeiden, skaliert die Anwendung auf einem Multicore-System in entsprechender Weise.

All diese Fehler können Sie übrigens von Anfang an vermeiden, indem Sie Tools wie den VTune Performance Analyzer einsetzen, der Ihnen genau die Stellen zeigt, die man am besten parallelisieren kann. Aber auch das Laufzeitverhalten einer fertigen Anwendung kann mit VTune erforscht werden. Und wenn Sie dann mal ein parallel programmiertes Programm vorliegen haben, hilft der Thread Checker dabei, mögliche Fehler aufzuspüren. Hierbei sind Dead Locks und Race Conditions eine häufig auftretende Fehlerquelle, die sich mithilfe des Tools lokalisieren lassen.

J, ja, es ist schon ein paar Tage her, dass Mac OS X 10.5, auch bekannt als Leopard, das Licht der Welt erblickt hat. Aber ich habe gerade ein paar sehr interessante Details bezüglich der Multicore-Affinität des Apple-Betriebssystems entdeckt. Und so richtig viel darüber habe ich im Web nicht gefunden.

Hardware-seitig bietet Apple ja mit dem Mac Pro die volle Mehrkerntechnik von Intel: Acht Prozessorkerne beschleunigen vor allem die Bild- und Videobearbeitung, aber auch für Apple-eigene Anwendungen ist der Intel Xeon Prozessor, eine Quadcore-CPU mit maximal 3,2 GHz, nützlich.

Von dieser Mehrkern-Architektur profitieren unter anderem Programme wie Mail, das Adressbuch und die Verwaltung der Schriftensammlung, indem anfallende Aufgaben auf die vorhandenen Ressourcen möglichst optimal verteilt werden. Darum kümmert sich übrigens die neu programmierte Ablaufsteuerung von Leopard.

In Sachen Netzwerk hat sich Apple ebenfalls Gedanken gemacht: So wurde ein multithreading-fähiger Netzwerkstapel implementiert, der die Ein- und Ausgabeanfragen des LANs schneller verarbeiten kann. Außerdem wurde die indizierte Suchfunktion Spotlight beschleunigt, genauso wie die Wörterbuchfunktion von Mac OS X 10.5. Dies hat vor allem mit der objektorientierten API Cocoa zu tun, die ebenfalls für den Multicore-Betrieb optimiert wurde.

Um all diese Verbesserungen hinsichtlich der parallelen Datenverarbeitung zu erzielen, hat Apple seinem Betriebssystem eine ganz neue Klasse an APIs spendiert, die sogenannten NSOperationen. Dabei werden unabhängig voneinander berechenbare Operationen einer Warteschleife hinzugefügt, die automatisch und sehr dynamisch die Verarbeitung der Befehle oder Operationen steuert, je nach Auslastung der vorhandenen Prozessorkerne.

Interessant daran ist auch die Tatsache, dass man als Entwickler die erforderlichen Threads nicht selbst erstellen und wieder schließen muss. Dies erledigt Cocoa automatisch, indem es die Operationen selbstständig auf die Ressourcen effizient verteilt.

Darüber hinaus lassen sich Leopard-basierte Macs (vor allem der bereits erwähnte Mac Pro) für wissenschaftliche Zwecke einsetzen, da Apple auch hier auf die Multicore-Fähigkeiten seiner Rechner setzt. Das Zauberwort heißt OpenMPI, was eine Vernetzung mehrerer Rechner ermöglicht. Dabei kommen mediumseitig IP-Verbindungen wie LAN oder WLAN zum Einsatz, die Software für den eigenen Mac-Cluster nennt sich Xgrid und stammt ebenfalls von Apple. Selbst in der Entwicklerumgebung Xcode steckt eine Menge Multicore-Potenzial, wie wir ja bereits in einem früheren Beitrag gezeigt haben. Parallel Computing aus dem Hause Apple von A bis Z eben …

Wie aber sieht es mit den fundamentalen Tools aus, die bei der Programmierung an erster Stelle stehen, also etwa den Compilern, mit denen sich der Quellcode in eine ausführbare Anwendung verwandeln lässt? Nun, auch hierfür gibt es multicore-optimierte Lösungen, die sich vor allem an C++- und Fortran-Programmierer richten. Das Ganze gibt es sogar als komplettes Entwicklerpaket, das neben dem C++-Compiler die TBB-Suite umfasst, die Integrated Performance Primitives und die Math Kernel Library.

Praktisch an dem Intel C++-Compiler für Windows sind vor allem zwei Dinge: Zum einen lässt er sich direkt in Visual Studio einbinden, was das Kompilieren innerhalb der gewohnten Umgebung ermöglicht. Und zum anderen ist der Compiler für Multicore-Plattformen optimiert. Das bedeutet, dass der Quellcode auf mögliche Parallelitäten hin untersucht wird. Findet der Compiler entsprechende Programmabschnitte, fügt er automatisch die passenden Konstrukte und Funktionen ein, die den seriell programmierten Abschnitt parallelisieren.

Neu an der Version 11 des Intel C++-Compilers sind übrigens unter anderem die eingebauten Lambda-Funktionen, OpenMP 3.0 und die Unterstützung von dezimalen Fließpunktoperatoren und -registern. Und natürlich gibt es die Intel Compiler auch für Linux (inklusive Eclipse-Unterstützung) und für Mac OS X (in Verbindung mit XCode).

Die Intel TBB lassen sich in sechs fundamentale Einzelteile zerlegen:

1. Algorithmen
2. Container
3. Memory Allocator
4. Mutual Exclusion
5. Timer
6. Task Scheduler

1. Die TBB-Algorithmen richten sich vor allem an parallel ausführbare Schleifenkonstrukte, aber auch Sortieralgorithmen lassen sich mithilfe der TBB recht problemlos parallelisieren. Die zugehörigen Funktionen nennen sich parallel_for, parallel_reduce, parallel_scan, parallel_while, parallel_pipeline und parallel_sort. Eine genauere Betrachtung dieser Funktionen findet auf dem Software Dev Blog in einem späteren Beitrag statt.

2. Die Intel TBB setzen sich aus drei Containern zusammen: queue, vector und hash table. Diese Container findet man zwar auch in den Standard Template Libraries von C++ und Fortran, diese sind allerdings weniger thread-sicher als die der Intel TBB.

3. Der Memory Allocator der Intel TBB ist äußerst skalierbar und daher in der Lage, gemeinsam genutzten Speicher auf mehrere Threads so zu verteilen, dass sich diese nicht gegenseitig behindern. Damit kümmert sich der Allocator der TBB um das gleichzeitige Ausführen der wichtigsten Funktionen wie malloc, new und delete.

4. Die Mutual Exclusions der Intel TBB kümmern sich um konsistente Daten bei der Ausführung paralleler Funktionen. Es geht also um das Sperren und Freigeben von Daten (Lock und Unlock) während der Ausführung verschiedener Threads. Somit ist gewährleistet, dass sich Threads bei der Manipulation von Daten nicht ins Gehege kommen, was zu richtigen Ergebnissen führen soll.

5. Die in den Intel TBB implementierte Timing-Funktion – also das Ermitteln der Programmdauer per Subtraktion zweier Uhrzeiten – ist für viele Entwickler ein wichtiger Aspekt. Von Bedeutung dabei ist aber auch ein Ergebnis, auf das man sich selbst dann verlassen kann, wenn der zugehörige Thread auf mehreren Prozessorkernen parallel ausgeführt wird.

6. Eine Kernfunktion der Intel TBB ist der Task Scheduler, der die Vielzahl unterschiedlicher Aufgaben, die mithilfe der Algorithmen aus Punkt 1 definiert werden, auf die vorhandenen Threads, also Prozessorkerne, optimal verteilt. Um dies zu garantieren, beherrscht der Task Scheduler das Load Balancing, was dazu führt, dass parallele Aufgaben möglichst effizient von den vorhandenen CPU-Cores ausgeführt werden. Folge: Maximale Performance der Anwendung!

1. Untersuche! Und zwar den gesamt Quellcode auf potenzielle Parallelisierung hin. Hierfür eignen sich vor allem Schleifenkonstrukte, die beispielsweise eine große Menge an Daten berechnet, was oft simultan geschehen kann. Es geht aber auch um “Hotspots”, die es in jedem Programm gibt und die die Leistungsfähigkeit der Anwendung negativ beeinträchtigen können. Um diese Untersuchungen möglichst effizient durchzuführen, gibt es spezielle Tools wie den VTune Performance Analyzer, der genau für diese Aufgaben geschaffen worden ist.

2. Kodiere! Und zwar parallel. Nachdem die passenden Programmstellen identifiziert worden sind, beginnt die eigentliche Arbeit, nämlich die des Kodierens. Packen Sie also all den parallelen Code in Ihr Programm, von dem Sie glauben, dass er Ihre Anwendung schneller macht, da sie von den vorhandenen Prozessorkernen profitiert. Und Sie können es sich dabei ein wenig leichter machen, indem Sie auf Tools zurückgreifen, die Ihnen mithilfe vorgefertigter Routinen und Bibliotheken dabei helfen. Dies können einfache Anweisungen paralleler Schleifenkonstrukte sein, aber auch komplexe Funktionen für Multimedia- oder Wissenschaftsanwendungen.

3. Debugge! Nachdem der Quellcode Ihrer Anwendung möglichst gut für die parallele Ausführung optimiert worden ist, steht noch eine Menge Debug-Arbeit auf dem Plan. Auch hierfür gibt es die passenden Tools, denn nur schwer auffindbare Fehler wie Dead Locks oder unvorhersehbare Race Conditions lassen sich mit einfachen Testmethoden gar nicht oder nur sehr aufwendig identifizieren. Ziehen Sie hierzu am besten die passenden Tools zu Rate wie den Thread Checker, der genannte Fehlerquellen aufdeckt und Ihnen genau sagt, welche Quelltextstellen kritisch bzw. fehleranfällig sind.

4. Optimiere! Jetzt haben Sie es fast geschafft, aber noch können Sie sich nicht sicher sein, dass Ihre Multicore-Anwendung auch wirklich optimal läuft. Denn noch können einzelne Codeteile den gesamten Programmablauf ausbremsen, da beispielsweise die Speicherverwaltung nicht effizient erfolgt oder die Anwendung nicht richtig skaliert. Das bedeutet im schlimmsten Fall, dass Ihre Software zwar auf einem Dualcore-Rechner perfekt läuft, es auf einer Quadcore-Maschine aber permanent zu Wartezeiten kommt, da mehr Threads zur Laufzeit erzeugt werden als Prozessorkerne vorhanden sind. Auch für diese Zwecke gibt es die entsprechenden Tools: den schon erwähnte VTune Analyzer, aber auch den Intel Thread Profiler, der die Effizienz des parallelisierten Code grafisch darstellt und Ihnen so hilft, Schwachstellen schneller und leichter zu lokalisieren.

Wie gut, dass es für die Parallelisierung solcher Anwendungen die passenden Tools gibt, die Intel unter dem Begriff „Performance Libraries“, also Hochleistungsbibliotheken, anbietet. Dazu gehören die schon besprochenen Intel Threading Building Blocks, aber auch spezielle C++-Bibliotheken namens Intel Integrated Performance Primitives (Intel IPP) und Intel Math Kernel Library (Intel MKL).

Die Intel IPP wenden sich an all diejenigen, die programmierseitig viel mit En- und Dekodern für Audio- und Videoinhalte zu tun haben, aber auch mit Datenkompression, Spracherkennung und Bildbearbeitung. Für all diese (und weitere) Anwendungen bieten die Intel IPP nämlich die passenden Bibliotheken, die sich mit wenig Aufwand in das eigene Softwareprojekt integrieren lassen. Man muss ja schließlich das Rad nicht jedes Mal neu erfinden. Außerdem kann man sicher sein, dass die IPP in höchstem Maße multithreaded sind.

Aber auch die Intel MKL bietet vorgefertigte Bibliotheken, Funktionen und Konstrukte, die sich mit wenigen Anpassungen in eigene Projekte einbinden lassen. Dies betrifft vor allem Wissenschafts-, Entwickler- und Finanzanwendungen. Die Intel MKL setzt hierfür unter anderem auf hoch parallelisierte Fast-Fourier-, Statistik- und LAPACK-Routinen.

Intel IPP und Intel MKL unterstützen Windows, Linux und Mac OS X und lassen sich problemlos in Visual Studio 2003, 2005 und 2008 integrieren. Beide Toolsets sind zudem Teil der Intel C++-Compiler Professional Edition. Außerdem können die Multicore-Bibliotheken zu Evaluationszwecken ausgiebig getestet werden. Hierfür muss man sich nur einmal für die jeweilige Software anmelden, was kostenfrei ist.

Damit steht der Thread Checker in der bekannten Entwicklungsumgebung zur Verfügung. Eine Einschränkung gibt es allerdings: Es lassen sich nur nativ programmierte Anwendungen mit dem Thread Checker überprüfen, also nur C++ und Visual Fortran. .NET-Entwickler bleiben derzeit leider außen vor. Dies wird sich allerdings mit Visual Studio 2010 ändern, das ja Ende nächsten Jahres auf den Markt kommen soll.

Exkurs: Race Conditions und Dead Locks
Race Conditions treten vor allem dann auf, wenn ein parallel programmiertes Programm zur Laufzeit zwei Thread generiert, die beide auf ein gemeinsames Datum zugreifen und davon nichts wissen. So erzeugt Thread A beispielsweise ein Datum X und speichert es, was Thread B genauso tut, ohne darüber Bescheid zu wissen, dass Thread A das Datum X gerade geändert. Dies kann natürlich zu unvorhergesehenen Problemen und Fehlern im weiteren Programmablauf führen.

Bei Dead Locks hingegen verhält es sich genau umgekehrt: Dort warten zwei Threads gemeinsam auf eine bestimmtes Ereignis, das aber niemals eintreten wird. Folge: Das Programm begibt sich in eine Endlosschleife, aus der es nicht mehr herausfindet.

Der Intel Thread Checker ist also ein hoch entwickelter Debugger, der Multithread-Fehler aufspürt, die mithilfe von Windows-, POSIX- und OpenMP-Thread-Tools sowie den Threading Building Blocks erzeugt wurden. Und das gilt nicht nur für aktuelle Fehler, sondern auch für potenzielle, die der Thread Checker bei seinen Untersuchungen finden kann. Das Intel-Analysetool gibt es sowohl für Windows XP und Vista in der 32- und 64-Bit-Variante als auch für Linux, allerdings nicht für Itanium-Plattformen.

Webast-Tipp: Auf der Webseite der SOS Software Service GmbH findet sich ein sehr fundiertes Videotutorial zum Thema Thread Checker. In diesem Webcast wird auch ein weiteres Analyse-Tool von Intel besprochen, nämlich der Thread Profiler.

Einer der vier Teilprogramme von Parallel Studio nennt sich Parallel Composer, der es Software-Entwicklern dank vorgefertigter Bibliotheken, Funktionen und Programmschnipseln relativ einfach machen soll, ihrem Quellcode paralleles Leben einzuhauchen. Und mit dem gestrigen Tag wurde das Beta-Programm für den Parallel Composer gestartet. Wer also unter C++ programmiert, hierfür Windows Visual Studio 2005 oder 2008 einsetzt und seine Anwendungen für Intel-Multicore-CPUs optimieren will, sollte sich eine Beta-Version des Parallel Composers besorgen.

Neben dem Beta-Programm für den Parallel Composer stellt Intel eine Menge Hilfe, Tipps und Tricks rund um das parallele Programmieren mit dem neuen Tool zur Verfügung. Ob das Hilfestellungen bei Installationsproblemen sind oder nützliche Tipps, wie sich der Intel C++-Compiler innerhalb des Microsoft Visual Studio Team Foundation Server einsetzen lässt – hier findet man eine Menge Antworten auf seine Fragen rund um den Intel Parallel Composer.

Hinweis: Ich muss noch eines klar stellen: Die Beta-Phase des Intel Parallel Studio hat entgegen früherer Ankündigungen noch nicht begonnen, was aber nur einen kurzen Aufschub bedeutet. Daher wird das Ganze mit einem Teilprogramm, dem Parallel Composer, gestartet.

Videotipp: Wer mehr in Bild und Ton zum Intel Parallel Studio im Speziellen und zum parallelen Programmieren unter Windows im Allgemeinen lernen will, sollte sich mal die Videochats mit Ralph de Wargny von Intel und Steve Teixeira, Parallel-Guru von Microsoft, ansehen.

Was funktioniert am allerbesten, wenn man eine neue Technologie oder ein neues Produkt präsentieren will? Richtig, eine Live-Demo. Zwar ist ein Videoclip nicht wirklich live, aber wenn es eindeutig ist, dass am Inhalt nicht herumgeschraubt wurde, ist die Beweiskraft dieses Mediums sehr hoch.

So verhält es sich auch mit der 3D-Demo, die ich gerade auf der ISN-Webseite gefunden habe. Ihr Name: Smoke. Ihr Ziel: das Leistungspotenzial des neuen Core i7 Prozessors demonstrieren. Die Zutaten: eine hochkomplexe 3D-Szene mit einem brennenden Haus und diversen AI-Objekten wie herumfliegenden Vögeln, im Wind schwankenden Bäumen und einigem mehr.

Das Beeindruckende an der Demo ist deren Skalierbarkeit: Ausgelegt auf einen Core i7 Quadcore-Prozessor laufen gleichzeitig acht Threads ab, und das mit nahezu voller Auslastung. Sobald sieben der acht Threads abgeschaltet werden, geht die 3D-Szene erkennbar in die Knie: Das Feuer verkommt zu Pixelwolken, sämtliche AI-Objekte wirken schlagartig unnatürlich und mit dem 3D-Erlebnis ist insgesamt Schluss.

Gesteigert wird das Ganze übrigens durch eine Löschaktion, die ins Spiel kommt und die die Komplexität der gesamten Demo weiter erhöht. Doch dem Core i7 ist das egal: Er verrichtet unbeirrt seinen Dienst, als ob nichts geschehen  wäre.

Intel wäre natürlich nicht Intel, wenn der gesamten Demo nicht Intel-Technologien zugrunde lägen: Das Parallelisieren des Demo-Codes geschah mithilfe der Threading Building Blocks, die physikalische Simulation basiert auf der Havok-Technik und sämtliche 3D-Szenen werden mit Ogre3D verwaltet.

Das Gute an der Demo: Sie steht zum kostenlosen Download bereit, und den Sourcecode gibt es natürlich auch gleich dazu. Inklusive interessanter Kommentare, wie diese komplexe 3D-Szene mithilfe geeigneter Multithreading-Techniken parallelisiert wurde. Lernen mit Intel, quasi!

Ach ja: Smoke läuft nicht auf jedem x-beliebigen Rechner, man sollte schon mindestens einen Core 2 Quad-Core im PC stecken haben. Das gilt auch für die Grafikkarte: Eine Nvidia 8800 GTS ist empfehlenswert, auf der wurde die 3D-Demo auch entwickelt.

Dabei geht es vor allem um das im Frühjahr nächsten Jahres erscheinende Tool Intel Parallel Studio. Es handelt sich um ein Plugin für Microsofts Entwicklungsumgebung Visual Studio. Parallel Studio soll vor allem C++-Entwicklern dabei helfen, ihre Anwendungen im Hinblick auf Multicore-Prozessoren wie den Intel Core 2 Duo zu optimieren.

Daher werden wir unter anderem C++-Programmierer vor der Kamera zu Wort kommen lassen, die sich für Parallel Studio begeistern können. Aber auch die Intel-Vorträge zu diesem Thema werden wir in Ton und Bewegtbildern festhalten und hier online stellen. Und klar, um ein wenig “Atmo” geht es auf der Tech-Ed EMEA 2008 natürlich auch. Mal sehen, was uns dort alles erwartet.

Apropos: Die Besucher der Intel-Vorträge, die im Presentation Pavillon in der Nähe des Intel-Standes (E5/E6) jeweils nachmittags (DI, MI und DO) stattfinden werden, sollten gut aufpassen. Denn es gibt im Falle richtig beantworteter Fragen ein Notebook mit Dual-Core-Proezessor zu gewinnen. Wenn das mal kein Anreiz ist! Und was sich hinter dem Intel Black Belt Software Developer verbirgt, erfahren Sie am Intel-Stand ebenfalls. Man sieht sich also …

Ok, das ist jetzt mehr als 15 Jahre her und wir hatten auch keine vernünftige Testumgebung zur Verfügung, aber das gute Trial-and-Error wird beim Aufspüren von Programmierfehlern immer noch gerne eingesetzt. Doch spätestens bei großen Projekten, die hunderte von Manntagen umfassen, greifen solche Ansätze nicht mehr.

Wie gut, dass es hierfür Tools wie den Intel VTune Performance Analyzer gibt, der Schwachstellen und Fehler aufspürt, was das Debuggen und Testen von Quellcode erheblich vereinfacht und beschleunigt. Hierzu bedient sich VTune verschiedener Ansätze, die bei der Fehlersuche angewandt werden:

• Ereignis-basiertes Sampling findet Flaschenhälse und Engpässe, die sich in den Quellcode eingeschlichen haben, ohne dabei unnötigen Overhead zu generieren. Solche Ereignisse sind Fehltreffer bei Cache-Zugriffen, falsche Vorhersagen bei Funktionsaufrufen und unzureichende Busbandbreiten.

• Der VTune Performance Analyzer identifiziert darüber hinaus exakt die Stellen innerhalb des Quellcodes, die bei der Ausführung am meisten Zeit benötigen. Damit lassen sich falsche Funktionsaufrufe und ähnliche Konstrukte relativ einfach bestimmen und wahlweise eliminieren oder optimieren.

• Mithilfe von Call Graph werden Funktionsaufrufe grafisch dargestellt und der jeweils zugehörige kritische Pfad ermittelt. Das hilft sehr intuitiv beim Aufspüren möglicher Engpässe und Problemstellen. Außerdem ermittelt VTune auf diesem Weg zeitintensive Funktionen.

• VTune Performance Analyzer ermittelt außerdem leistungshemmenden Quellcode auf Systemebene, indem mithilfe des Counter Monitors sämtliche Systemaktivitäten und die benötigten Ressourcen zur Laufzeit überprüft werden. Damit lässt sich beispielsweise feststellen, welche Programmteile unverhältnismäßig viel Speicher vereinnahmen.

Sehr praktisch an VTune ist seine Unabhängigkeit: Das Tool kann mit sämtlichen gängigen Compilern eingesetzt werden, also von Microsoft, Intel oder GNU, und zwar für C++, Fortran und Microsoft .NET inklusive C# und Visual Basic.

Immer noch nicht vom VTune Performance Analyzer überzeugt? Dann sollten Sie mal bei Musicmatch, Adobe, Nvidia, Yahoo oder Microsoft nachfragen. Die finden VTune nämlich sehr praktisch und wollen darauf nicht mehr verzichten. So wurden beispielsweise Microsoft Excel und den Grafiktreibern von Nvidia mehr Leistung eingehaucht.