Die Macher von Shrek, Dreamworks Animation, haben nämlich eine Art “Mooresches Gesetz” für Animationsfilme entwickelt. Diese Regel besagt, dass sich mit jeder Shrek-Episode die notwendige Rechenleistung verdoppelt hat. Benötigte also Shrek I vor zehn Jahren etwa fünf Millionen CPU-Stunden zum Rendern des fertigen Films, so kam Shrek 2 bereits auf mehr als 10 Millionen Prozessorstunden für die notwendige Render-Leistung. Und der “aktuelle” Shrek-Film aus dem letzten Jahr erforderte eine unglaubliche Rechenleistung von 50 Millionen CPU-Stunden – und das nur für das Erstellen der 3D-Bilder. Die Konsequenzen für den benötigten Rechner-Park muss ich ja wohl nicht extra ausführen, oder?

Da es Dreamworks Animation sinnvoller erschien, anstatt ständig in neue Hardware eher in die Render-Software zu investieren, setze man sich mit diversen Intel-Ingenieuren zusammen und entwarf einen Plan, wie die Dreamworks-Render-Werkzeuge so zu optimieren seien, damit aus den 50 Millionen Render-CPU-Stunden möglicherweise 20 Millionen oder weniger Stunden werden können. Nun, die Ergebnisse des Brainstormings lassen sich wie folgt zusammenfassen:

• Mit Hilfe von OpenMP ließen sich zahlreiche Abschnitte des Render-Codes parallelisieren. Um diese kritischen Code-Regionen exakt und mit möglichst geringem Aufwand ausfindig machen zu können, setzten die Intel-Ingenieure auf Intel Inspector XE 2011. Damit ließen sich die Render-Werkzeuge zudem auf mögliche Dead-Lock- und Data-Race-Probleme hin untersuchen.

• Dank des Tools Intel C++ Compiler Threading Diagnostisch, der Teil des Intel C++-Compilers ist, konnten globale Variablen identifiziert werden, die beim gleichzeitigen Zugriff auf gemeinsam genutzte Daten erhebliche Probleme innerhalb parallel programmierter Abschnitte machen können.

• Aber auch das Intel C++ Compiler Code Coverage Tool (ebenfalls Teil des Intel C++-Compilers) kam zum Einsatz. Damit lassen sich nämlich sämtliche Programmteile anzeigen, die vom Inspector XE 2011 analysiert worden sind. Das erhöht das Verständnis für die möglichen Optimierungen des eigenen Sourcecodes ganz erheblich.

Es ist wohl überflüssig zu erwähnen, dass all diese Maßnahmen nicht nur zu schnellerem, sondern auch zu thread-sicherem Code geführt haben. Denn bei aller Euphorie hinsichtlich kürzerer Render-Zeiten darf die Laufzeit-Sicherheit auf keinen Fall zu kurz kommen.

So, und falls Sie an detaillierteren Infos zu den einzelnen Optimierungen der Render-Tools von Dreamworks Animation interessiert sind, sollten Sie unbedingt den zugehörigen Blogbeitrag auf software.intel.com lesen.

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.

Das bestätigen erfolgreiche Spielefirmen. Entwicklerschmieden wie Creative Assembly (“Empire: Total War”), Kingsoft (“JX3″), Codemasters (“Dirt 2″) und Gas Powered Games (“Demigod”) setzen Intel GPA bereits eine ganze Weile erfolgreich ein. Hier ein paar Statements der Software-Häuser zu dem Profiling-Tool von Intel:

Jeder einzelne API-Call wird zeitlich erfasst und ausgegeben. Man sieht also ganz genau, wie lange der Grafikprozessor für die Berechnungen benötigt, und kann auf dieser Basis den Code entsprechend optimieren, damit das Spiel flüssig auf einem Onboard-Grafikchip läuft. (Yuri O’Donnell, Creative Assembly)

Mithilfe von Intel GPA konnten wir recht einfach zwei Störenfriede in Form von Bottleneck aufspüren und eliminieren. Das verhalf uns zu einer 30-prozentigen Leistungssteigerung des Spiels. Ganz erstaunlich! (Richard Broadhurst, Creative Assembly)

Das Hauptziel war es, die Framerate unseres Spiels “JX3″ um den Faktor 2.1 zu erhöhen, ohne dass die Darstellungsqualität der gerenderten Bilder darunter leidet. Dank Intel GPA können wir sagen: Mission accomplished! (Kingsoft)

Intel GPA ist ein wirklich cooles Tool. Es hat uns dabei geholfen, “Ghostbusters” für Intel Onboard-Grafikchips zu optimieren. Dabei ging es vordergründig um die Frage, wie wir es schaffen können, so wenig wie möglich an Details zu verlieren und gleichzeitig so viel wie möglich Merkmale zu erhalten (Schatten, Reflexionen, etc.). Ich muss sagen: wir haben mithilfe von Intel GPA die passenden Antworten gefunden. (Mark Randel, Terminal Reality)

Wir arbeiten schon seit längeren mit Tools wie VTune Performance Analyzer, Intel Thread Profiler und Intel GPA. Und ich muss sagen: Ohne diese Tools wären wir nicht in der Lage gewesen, die Framerates unserer Spiele auf ein solch hohes Level zu bringen, wie wir es heute gewohnt sind. Hoffentlich können wir auch in Zukunft dazu beitragen, diese Tools noch ein wenig besser zu machen. (Graham Watson, Codemasters)

Intel GPA lässt sich einfach bedienen und erzeugt all die Informationen, die wir für das Optimieren der Render-Pipelines und der Gesamt-Performance unserer Spiele benötigen. Darüber hinaus ist es ein prima Debugging-Tool. Intel GPA hilft uns wirklich, unsere Effizienz zu verbessern. (777 Studio, “Rise of Flight”)

Mithilfe von Intel GPA konten wir Civilization V für sämtliche am Markt befindlichen Grafikchips optimieren – von Onboard-GPUs bis hin zu Highend-Karten. Dank des GPA-Tools “Platform View” – in Kombination mit Intel TBB – konnten wir unseren Spielecode so optimieren, dass er von sämtlichen verfügbaren Prozessoren maximalen Gebrauch macht – 6-Kern-Core-i7-CPU inklusive. (Dan Baker, Firaxis)

Intel hat die Version 4 der Toolsuite Graphics Performance Analyzers (GPA) veröffentlicht, die selbstverständlich auf die Sandy Bridge-Architektur hin optimiert wurde.  Dabei handelt es sich um ein Set von Software-Tools, das Spiele-Entwicklern  dabei hilft, die Performance der eigenen Applikationen zu verbessern.

GPA visualisiert die Performance-Werte und zeigt deutlich, in welchen Frames die Schwachstellen zu finden sind. Zudem ermöglicht es „Was-wäre-wennn“-Analysen in Echtzeit, um die optimalen Grafikeinstellungen und -werte zu ermitteln. Zur Analyse typischer CPU-Probleme sind hingegen andere Intel-Tools wie Intel VTune Performance Analyzer und Intel Parallel Studio besser geeignet.

Die neue Version 4 bietet signifikante Verbesserungen, die weitestgehend aus dem Feedback der bestehenden Anwender resultieren und wendet sich an Programmierer für Windows (7, Vista, XP mit DirectX in den Versionen 9-11).

Der Download ist für registrierte User kostenlos.

Vorteile der neuen Version

Insgesamt sorgt ein verbessertes Programmdesign dafür, dass Sie Ihre Spiele-Apps intuitiv und schneller analysieren können. Zudem erweitert die Microsoft DirectX 11-Unterstützung das Spektrum der Spiele, die Sie testen und optimieren können.

Weitere Vorteile in Stichpunkten:

• Voll konfigurierbare Funktion für automatisch ablaufendes Capturing von Frames oder Trace Files (etwa alle Frames, die langsamer als 20 FPS sind)
• Screenshot-Vorschau in Thumbnails erleichtert die Auswahl der Frames
• Neue “How to”-Videos helfen Neulingen bei den ersten Schritten mit GPA
• Das neue GPA-System Analyzer Heads-Up Display (HUD) ermöglicht eine intuitive Analyse und ist bereits für die aktuellen GPU-Metrics auf Intel HD Graphics 2000/3000 Hardware (GPU bei Sandy Bridge) gerüstet, um gerade dort die Bottlenecks in den Apps festzustellen
• Intel Graphics Frame Analyzers unterstützt Multiple Render Targets (MRT)
• Es werden mehr Texturen als bisher unterstützt

Für den Einstieg in das Tool hat Intel einen Quickstart-Guide und eine FAQ-Seite 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.

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!

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.

• das richtige Speicher-Management beim Threaden von Anwendungen

und

• der richtige Einsatz der bestehenden Intel-Tools wie Integrated Performance Primitives und Parallel Inspector, Parallel Amplifier und Parallel Composer.

Toll an diesem Programmier-Leitfaden ist die sehr ausführlich Darstellung möglicher Szenarien und wie sich diese richtig behandeln lassen. Dazu gibt es eine Menge nützlicher Diagramme und Code-Beispiele.

Allerdings hat Intel vor den Download dieser digitalen Broschüre eine kleine Registrierung gestellt, die aber nur aus einem Namen und einer E-Mail-Adresse besteht. Anschließend könnt ihr sogar auswählen, welche Themen und Broschüren euch besonders interessieren. Im Falle der Multithreading-Anleitungen solltet ihr “Intel Software Dispatch” anklicken. Viel Spaß beim Lesen!

In dem ausführlichen Beitrag wird gezeigt, wie das Intel-Tool dabei helfen kann, serielle Codeabschnitte zu parallelisieren. Ach ja: Das betrifft ausschließlich C++-Programmierer. Toll an Advisor Lite ist sein schrittweises Herantasten an den möglichen Multithread-Code: Anstatt alles auf einmal umzustellen, erlaubt das Tool ein sukzessives Optimieren des seriellen Quellcodes. Hierzu setzt es vorhandene Debugger-Tools ein, mit denen der parallelisierte Quellcode sofort getestet und mögliche Fehler identifiziert und eliminiert werden können. Dazu zählen unter anderem Data-Sharing-Probleme, die sich beim Synchronisieren von Threads ergeben können.

Interessant an Edmunds Artikel ist übrigens die Vorgehensweise des Advisor Lite:

1. Leistungsengpässe (Hotspots) identifizieren
2. Annotationen in den seriellen Quellcode einfügen (eine Art von C-/C++-Makros)
3. die  annotierten Quellcodes verifizieren
4. parallele Datenzugriffe untersuchen
5. Datenkonflikte auflösen, die unter Schritt 4 aufgespürt wurden
6. Quellcodeänderungen testen

Ach ja: Wer noch nicht wissen sollte, was Annotationen sind: Sogar hierzu hält Edmund die passenden Antworten parat. Also alles in allem eine wirklich gelungene Abhandlung in Sachen Parallel Advisor Lite. Und, worauf wartet ihr noch?

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!

So viel Verbesserung in Sachen Performance lässt sich unter anderem mit Multicore-Optimierungen seitens der Avast-Entwickler bewerkstelligen. Damit erfolgt beispielsweise der Echtzeit-Scan auf einem Prozessorkern, während die GUI von einem zweiten Kern ausgeführt wird, was die Software insgesamt performanter macht.

Was die Leute bei Avast alles dafür getan haben, um ihre Software multicore-tauglich zu machen, werde ich versuchen herauszufinden. Sobald ich die passenden Antworten habe, werden sie natürlich hier veröffentlicht.

PS: Falls ihr Avast Free Antivirus installieren wollt, solltet ihr vorher unbedingt die bereits installierte Antiviren-Software deinstallieren. Ansonsten legt ihr euch möglicherweise den PC selbst lahm.

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!

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!

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.

Das ist mittlerweile viele Jahre her, und Anno Domini 2009 kommt Colin McRae DiRT 2 als weiteres PC-Highlight in die Regale, wenn auch mit Verspätung. Der Grund hierfür ist recht einfach: DiRT 2 benötigt für die volle Performance und Schönheit DirectX 11. Die Grafikschnittstelle steht erst mit Windows 7 auf PCs zur Verfügung und Window 7 erscheint am 22. Oktober. Zudem muss natürlich eine passende Grafikkarte im Rechner stecken, und auch die ist noch nicht verfügbar.

Dann geht`s aber richtig los mit Colin McRae DiRT 2. Dafür sollen Features wie Hardware-Tesselation, Shader Model 5.0 und Multithreading sorgen. Was sich genau dahinter verbirgt und was die McRae-Fans davon haben werden, will ich ganz genau wissen und habe beim zuständigen Produktmanager von Codemasters nachgefragt. Ich hoffe, seine Antwort lässt nicht zu lange auf sich warten – damit ihr bald wisst, wie es Codemasters schafft, Colin McRae DiRT 2 den angeblichen Fotorealismus einzuhauchen.

Zu den Anwesenden und Vortragenden gehörte auch Jonathan Heiliger, seines Zeichens Vice President of Technical Operations der Social-Media-Plattform Facebook. Heiliger diskutierte mit Om Malik, Gründer von Gigacom Network, die Frage, wie viel Infrastruktur solch eine riesige Plattform wie Facebook benötigt und wie sich diese in Sachen Server- und Datenbankzugriffe beherrschen lässt.

In diesem Zusammenhang berichtete Mister Heiliger unter anderem darüber, dass sich Facebook aus Performance- und Skalierungsgründen neue Server mit den aktuellen Prozessoren angeschafft hat, um dem steigenden Ansturm von Facebook-Anwendern besser gerecht zu werden. Jedoch empfindet er die Mehrkosten wohl nicht als gerechtfertigt, da seinen Worten zufolge die Performance durch die neuen Chips zu wenig zugelegt hat. Außerdem merkte er an, dass Facebook die gegenüber der Presse propagierten Leistungsschübe bei der Performance ihrer Applikationen nicht sieht.

So weit, so gut. Dabei beschleicht mich das Gefühl, dass es sich Facebook damit ein wenig zu leicht macht. Denn die aktuellen Prozessoren skalieren nur dann wirklich, wenn die betreffenden Serveranwendungen das Leistungspotenzial der Rechnerfarm auch vernünftig ausnutzen. Ich gehe mal davon aus, dass sich Jonathan Heiliger und seine Mitarbeiter schon mal mit dem Thema HPC-konforme Anwendungen beschäftigt haben. Oder, Jonathan?!

(via computerworld.ch)

Vergeben werden die Plätze eins, zwei und drei in den Kategorien “Bestes Multicore-Spiel”, “Bestes Notebook-Spiel” und “Bestes 3D-Chip-Game”. Zu gewinnen gibt es einen ganzen Haufen an Entwicklertools, Tickets zu großen Entwicklerkonferenzen und PCs im Wert bis zu 4.000 US-Dollar. Und, ist das nix?

Falls das für euch interessant ist, solltet ihr euch möglichst schnell für den Wettbewerb “Level Up 2009″ registrieren und euer optimiertes Computerspiel anmelden. Auf dass ihr zu den glücklichen Gewinnern zählt!

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.

• 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.

Eric Moore wird auf die bekanntesten Fehler eingehen, die man bei der Parallelisierung von Software machen kann, und zeigt, wie sich diese vermeiden oder auch eliminieren lassen. Hierzu zieht er bekannte und unbekannte Software-Titel zu Rate, anhand derer die Optimierung von Multithread-Code demonstriert werden soll.

Falls das also interessant scheint, solltet ihr euch möglichst schnell für das kostenlose Webinar anmelden und den Worten Erics lauschen. Viel Spaß dabei!

So, und falls jetzt einer von euch aufspringt und schreit “Ja, hier, ich, ich habe mein Spiel multithread-tauglich gemacht und habe ihm mobile Features verpasst und habe es sogar noch für integrierte Intel-Grafikchips optimiert”, dann sollte sich der- oder diejenige ganz schnell für einen Wettbewerb anmelden, der sich “Level Up 2009″ nennt und der im Rahmen der “Intel Visual Adrenaline Game Demo Challenge” stattfindet.

Der Anmeldeschluss ist übrigens der 1. Juli 2009. Ihr solltet also möglichst schnell das zugehörige Online-Formular ausfüllen, damit ihr auch bis zum 1. Juli von Besuchern der Wettbewerbsseite beurteilt werden könnt (das hat allerdings keinen Einfluss auf das Endergebnis). Solltet ihr für den Level-up-Contest zugelassen werden, bekommt ihr von Intel erst mal eine Menge an Software kostenlos zur Verfügung gestellt. Das sind im einzelnen:

• 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

Zwar umfassen diese Werkzeuge eine limitierte Lizenz, die bis zum 14. September läuft. Aber gerade für die Kategorie “Bestes Multithread-Game” leisten diese Tools sehr gute Dienste.

Ab dem 2. Juli setzt sich die Jury zusammen und befindet über die je zehn Finalisten der drei Kategorien “Multithreading”, “Laptop-Game” und “Spiel-ohne-Grafikkarte”. Am 20. Juli werden die Finalisten von Intel benachrichtigt und am 24. Juli werden deren Spiele online gestellt. Bis dahin muss auf jeden Fall eine lauffähige Demo vorliegen. Von Mitte bis Ende August werden die jeweils ersten drei Sieger gekürt und online vorgestellt. Und am 14. September werden die Gewinnertitel auf der Austin Game Developers Conference präsentiert. Und, ist das schick?!

Viel schicker wird’s aber noch, wenn ich euch erzähle, was es zu gewinnen gibt. Für den Ersten einer jeden Kategorie einen PC im Wert von 4.000 US-Dollar, eine Erwähnung in diversen Intel-Postillen, ein Entwickler-Softwarepaket im Wert von 4.300 Dollar, Intel-Entwickler-Tools für ein Jahr (Wert: 2.300 Dollar) sowie diverse Eintrittskarten zu diversen Konferenzen (die Flüge müsst ihr allerdings selbst zahlen). Und klar, die Plätze zwei und drei bekommen auch eine ganze Menge ab.

Und, sind das genug Gründe? Dann meldet euch am besten gleich für Level Up 2009 an und mit der entsprechenden Optimierungsarbeit und ein wenig Glück werdet ihr vielleicht der nächste Michael Capps.

Ach ja: Die gesamten Teilnahmebedingungen und sonstigen Infos findet ihr auf dieser Webseite. Und wer das Ganze auf Facebook nachlesen will, sollte einfach der zugehörigen Gruppe beitreten.

Jedoch gibt es mehr und mehr Ausnahmen von der Regel, wie ich ja hier schon anhand der Beispiele Nik Software, Crytek, Cakewalk und DivX gezeigt habe. Dazu gehört auch Nero, die schon seit der Version 7 ihrer Suiten Multithreading betreibt. Seitdem werden die Software-Titel wie Nero 9 immer weiter optimiert, um eine bestmögliche Ausnutzung der Hardware-Kapazitäten gewährleisten zu können. Hierfür arbeitet Nero sehr eng mit Intel zusammen, um in diesem Bereich optimale Ergebnisse erzielen zu können.

Am besten eignen sich bestimmte Anwendungstypen für das Multithreaden. Hierzu gehören beispielsweise Video-Encoder, ebenso Authoringtools. Daneben sind für Multicore diejenigen Nero-Tools optimiert, mit denen sich MPEG2-basierte DVDs in MPEG4-Videos konvertieren lassen, womit die notwendige Speicherkapazität halbiert werden kann. Gerade in diesen Disziplinen spielt die Datenparallelisierung eine ganz wichtige Rolle, da Encoderalgorithmen sehr multithreading-tauglich sind.

Ganz neue Software-Titel wie Nero Move it kommen ebenfalls in den Genuss des Multithreadings. Mit Move it lassen sich digitale Daten mit wenig Aufwand an das jeweils vorhandene Mobilgerät wie iPod und Musikhandy anpassen und dorthin übertragen. Nero setzt übrigens aus Performance-Gründen schon länger den VTune Perfermance Analyzer und Intel Compiler zu Analyse-, Optimierungs- und Testzwecken ein. Für eine bestmögliche Skalierbarkeit und Recheneffizienz.

Videotipp: Wer sich ansehen und -hören will, was Oberstratege Charly Lippoth (CSO) von Nero zu dem Thema zu sagen hat, sollte sich in folgendes Video reinklicken …

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!

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.

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.

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.

Natürlich wollten wir wissen, was DivX alles dafür getan hat, dass Version 7 unter anderem HD-Videos im H.264-Format bei voller Auflösung dekodieren kann, ohne dass es auf einem PC oder Notebook mit Core 2 Duo oder Quad ordentlich ruckelt. Heute kamen die Antworten bei uns an. Und das sind sie (inklusive ihrer Fragen):

Welche Softwaretools kamen zum Einsatz, damit DivX 7 vorhandene Multicore-Plattformen optimal unterstützt?

Antwort: Zunächst einmal haben wir ganz unten angefangen. Soll heißen, dass wir sämtliche DivX-Algorithmen auf Quellcode-Ebene mithilfe des VTune Performance Analyzer auf mögliche Flaschenhälse und damit auf potenzielle Optimierungsarbeiten hin untersucht haben. Das lieferte uns schon mal sehr interessante Anhaltspunkte. Darüber hinaus kamen eigene Tools zum Einsatz, um die Leistungswerte und die Qualität unserer Codecs zu überprüfen.

Doch nicht nur der Quellcode wurde untersucht, sondern auch die Anwendungen haben wir ausführlich unter diversen Bedingungen auf ihr Laufzeitverhalten hin analysiert. Dafür haben wir unter anderem Benchmark-Tools wie Sysinternals Process Explorer, Haali TimeCodec, Monogram GraphStudio, GraphEdit, AVISynth und VirtualDub eingesetzt.

Welche SSE4-Befehlsroutinen kommen in DivX 7 zum Einsatz, um ein Leistungsoptimum beim Kodieren und Dekodieren von Videostreams zu erzielen?

Antwort: Der DivX-7-H.264-Codec kommt noch ohne SSE4-Befehle aus, aber wir sehen uns das natürlich sehr genau an, um DivX noch leistungsfähiger machen zu können.

Gerade die zweite Antwort ist nicht wirklich ausgiebig, sodass wir uns kurzerhand am Mittwoch mit DivX treffen werden, um weitere Infos rund um die Multicore-Tauglichkeit von DivX 7 in Erfahrung zu bringen. Am besten nehmen Sie unser Blog schon mal in Ihren RSS-Reader auf. Dann bekommen Sie die Infos exklusiv und frei Haus geliefert …

Daher steckt eine ganze Menge Multicore-Potenzial in der Manipulation von Bildern, vor allem dann, wenn es sich um große Digitalfotos handelt. Dabei ist die Parallelisierbarkeit völlig unabhängig vom Format, so dass Bilder im sogenannten RAW-Format genauso von parallelisierten Algorithmen profitieren wie JPEG- oder TIFF-Dateien.

Wie wichtig in solch einem Fall das optimale Zusammenspiel von Hard- und Software ist, hat unter anderem Nik Software erkannt, ein Anbieter von Bildbearbeitungstools, die sich an professionelle Fotografen und ähnliche Menschen richten. Eines der Highlight-Produkte von Nik Software nennt sich Silver Efex Pro. Dabei handelt es um einen Schwarzweiß-Filter für Adobe Photoshop und Apple Aperture, mit dem sich Farbbilder in S/W-Kunstwerke verwandeln lassen. Hierfür setzt Nik Software auf die eigene Manipulationstechnik U Point, die es erlaubt, anhand definierter Bildbereiche (sogenannter Kontrollpunkte) diese separat zu bearbeiten.

Für eine bestmögliche Skalierung von Silver Efex Pro auf Multicore-Plattformen musste Nik Software allerdings eine ganze Menge tun. Hierzu gehörte unter anderem eine gründliche Analyse des Quellcodes mit VTune Performance Analyzer, um die Hotspots, also die kritischen Programmstellen, zu identifizieren.

Anschließend haben die Software-Entwickler die verschiedenen technischen Möglichkeiten geprüft, mit welchen Methoden die vorhandene Datenparallelität optimal in entsprechende Algorithmen umgesetzt werden kann. In Frage kamen hierfür OpenMP, die Threading Building Blocks und eine selbst implementierte Lösung auf Basis von Boost und Posix Threads.

Die Wahl fiel am Ende auf die selbst implementierte Lösung, da sie ein Maximum an Kontrolle, Flexibilität und Portierbarkeit gewährleistet. Die fertige Implementation des Thread pool pattern erlaubt hierbei eine relativ problemlose Übersetzung der Algorithmen in eine parallele Formulierung sowohl unter Windows als auch auf dem Mac.

Und klar, anschließend musste noch auf Teufel komm raus debuggt werden, und zwar mit den passenden Tools wie dem Thread Checker und Thread Profiler. Damit der parallelisierte Quellcode auch wirklich optimal auf mehreren Threads sprich Prozessorkernen skaliert. Und die Mühe hat sich offensichtlich gelohnt: Das Fotomagazin “Foto Video Digital” aus dem Hause Chip hat Silver Efex Pro als eine der besten Bildbearbeitungsprogramme des Jahres 2008 gekürt. Na also!

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!

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).

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.

Dass sich die Multithread-Optimierung für Crytek ausgezeichnet hat, zeigen auch die weiteren Preise in den Kategorien „Bestes Gamedesign“ und „Beste Spielegrafik“. Aber wie haben die das bloß gemacht?

Nun, sowohl im Falle von Crysis als auch Sacred haben beide Entwicklerfirmen ganz eng mit Intel zusammengearbeitet, um eine möglichst hohe Multicore-Optimierung hinzubekommen. So haben die Spieleentwickler von Crytek es geschafft, die unterschiedlichen Aufgaben wie das Rendering, die physikalischen Effekte wie Wind und Wasser und die Soundeffekte auf unterschiedliche Prozessorkerne zu verteilen, was die CPU extrem gut auslastet und damit für noch mehr Realismus und einen hohen Detailgrad sorgt.

Darüber hinaus haben sich die Entwickler von Crytek des Intel Laptop Gaming TDK bedient, das mit relativ wenig Aufwand beispielsweise das Einbinden einer Batterieanzeige in der Spielumgebung ermöglicht. Damit hat man als Notebook-Gamer stets die Restlaufzeit des Akkus im Auge. Mehr dazu gibt es übrigens in diesem Video.

Aber auch Sacred 2 kann mit einigen Überraschungen aufwarten. Dazu gehört die Optimierung des Spiels für integrierte Grafikchips, die auf Centrino 2 basieren. Damit läuft das RPG von Ascaron nicht nur in voller Auflösung und hohem Detailgrad auf einer Highend-Machine, sondern auch auf einem Einsteiger-Laptop, das ohne diskrete Grafikkarte auskommt. Auch hierfür war der Einsatz des Intel Laptop Gaming TDK notwendig.

Das TDK stellt ein weiteres Feature bereit, dass sich speziell an mobile Spieler richtet: Ad-hoc-Gaming. Dies ermöglicht per Mausklick die drahtlose Verbindung zwischen zwei Notebooks für einen unmittelbaren Multigamer-Spaß. Und auch dies geschieht direkt aus dem Spiel heraus und erfordert kein Verzweigen in die Windows-Systemeinstellungen. Und natürlich bietet Sacred 2 für Laptop-Gamer auch eine Batterie- und eine Wifi-Anzeige. Für die bestmögliche Kontrolle während des mobilen Spiels.

Alle, die sich den tragbaren Spielspaß mit Sacred 2 – Fallen Angel ansehen wollen, empfehlen wir dieses Video, das wir im August während der Games Convention Developers Conference 2008 gedreht haben.

Das bedeutet primär, dass die Videobearbeitung dank der acht gleichzeitig ablaufenden Threads auf den vier Prozessorkernen einen enormen Leistungssprung erfährt. Darüber hinaus profitiert PowerDirector 7 von der Intel QuickPath-Technologie und dem 8 MByte großen L3-Cache des Core i7 – für noch mehr Tempo beim Videoschnitt.

Der Quadcore-Prozessor ist unter anderem dafür verantwortlich, dass das Vorschau-Rendering schneller geschieht als auf herkömmlichen Quadcore-Rechnern, dass Effekte schneller verarbeitet werden und dass sich optische Medien noch schneller brennen lassen. So ist beispielsweise ein HD-Video, das mit dem rechenintensiven Pencil-Sketch-Effekt versehen wird, in weniger als einer Minute vollständig gerendert. Auf einem Core 2 Quad Q9550 benötigt derselbe Rechenaufwand zwei Minuten. Fazit: Die Wartezeit lässt sich mit dem Core i7 locker halbieren.

Wem diese Infos ein wenig zu dünn sind, der kann sich schon mal auf mehr freuen. Wir wollen nämlich auch wissen, an welchen Stellen Cyberlink Code-Optimierung vorgenommen hat und welche Tools hierfür zum Einsatz gekommen sind. Sobald wir diese Details vorliegen haben, gehen diese online. Versprochen!

Ach ja: Wer mehr zu PowerDirector 7 lesen will, kann dies auf der passenden Webseite tun.

Forget everything you thought you knew about multi-threaded programming (and, as it turns out, most developers didn’t know much anyway).

The kernel is the only one who really knows the right mix of cores and power states to use at any given time – this can’t be a pure app-driven decision.

We need new APIs and mechanisms for dealing with this incoming meteor.

Wie gut, dass sich Intel über Letzteres bereits Gedanken macht und Tools wie Intel TBB und Intel Parallel Studio bietet, mit deren Hilfe die Multicore-Programmierung deutlich erleichtert werden kann.

Weniger schlau während seines Vortrags war allerdings die Folie Nummer 5, auf der er (ganz inoffiziell natürlich) den Erscheinungszeitraum der nächsten OS-X-Version 10.6 aka Snow Leopard bekannt gegeben hat, nämlich das erste Quartal 2009. Anfang Juni während der Apple-Entwicklerkonferenz WWDC’08 war noch von ungefähr einem Jahr die Rede, bis Mac OS X 10.6 in die Läden kommt. Tja, dumm gelaufen!

Und was hat das alles mit Multicore-Programmierung zu tun? Nun, in der nächsten Version des Apple-Betriebssystems wird ganz viel Multicore-Unterstützung stecken. Leider gibt Apple noch nichts Konkretes raus (und John leider auch nicht), aber einige grundsätzliche Dinge sind heute schon klar:

Die Multicore-Technik in Snow Leopard trägt den Codenamen „Grand Central“ und soll laut Apple den Umgang mit Multicore-Systemen erheblich erleichtern. Das soll sowohl die Software-Entwickler betreffen als auch die Anwendungen und deren Ausführung. Es geht also um die Zuordnung von Tasks auf vorhandene Prozessorkerne und eine verbesserte Multicore-Programmierung unter Mac OS X 10.6. Das ist so überraschend nicht, schließlich weiß Apple seit vielen Jahren ganz genau, wie man Software und Hardware optimal aufeinander abstimmt.

Übrigens: Auch John Hubbards Chef, Mister Steve Jobs, kann gelegentlich nicht ganz so schlaue Dinge sagen. In einem Interview mit dem Bits Blog der News York Times sprach er nämlich folgenden Satz:

The way the processor industry is going is to add more and more cores, but nobody knows how to program those things. I mean, two,, [processor cores], yeah; four, not really; eight, forget it!

So, so, niemand weiß, wie man Software für vier, acht oder mehr Prozessorkerne programmiert. Na, Steve, frag mal bei Intel und seinen Partnern nach, wie das geht …

• Sämtliche verfügbaren Prozessorkerne samt der zugehörigen Threads, Caches und Schnittstellen werden dynamisch verwaltet und ermöglichen somit ein Maximum an Rechen- und Systemleistung.

• Die Intel Hyperthreading-Technologie erlaubt verbessertes Multithreading bei gleichzeitig optimiertem Energieverbrauch. Darüber hinaus lassen sich in Zukunft pro Prozessorkern zwei Threads gleichzeitig verarbeiten, was bei einem Core i7 mit vier CPU-Kernen acht parallele Threads bedeutet.

• Die Intel Streaming SIMD Extensions 4 (SSE4) konnten erneut verbessert werden, vor allem in Sachen XML-Verarbeitung.

• Verglichen mit den aktuellen Xeon-Prozessoren bietet der Core i7 dank seiner QuickPath-Architektur eine Bandbreite, die bis zu viermal so groß ist.

• Ein verbessertes Power Management erlaubt es Software-Entwicklern, ihre Anwendungen noch exakter auf die SSE4-Befehlssätze abzustimmen.

Da diese Infos aber nur einen kleinen Ausschnitt dessen wiedergeben, wozu der Core i7 im Stande ist, empfehlen wir weitere Informationen, die einen guten Überblick geben. Hierzu gehört beispielsweise ein Videoclip, der den neuesten Highend-Prozessor von Intel anschaulich erklärt, genauso wie ein Whitepaper, das im Detail auf die neue Mikroprozessor-Architektur eingeht, die hinter dem Core i7 steckt.

Gerade für Entwickler sind auch die SSE4-Infos wichtig: Diese zeigen, wie man Videokodierung mithilfe spezieller SSE4-Befehle optimiert, wie sich dank SSE4 der Speicherdurchsatz erhöhen lässt und wie man die XML-Verarbeitung beschleunigen kann, indem man die neuen SSE4-Befehle richtig einsetzt. Aber auch die PDF-Gesamtübersicht ist sehr hilfreich, wenn man alles über sämtliche neuen SSE4-Befehle wissen will.

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.

Nun, zunächst einmal gilt es, die gesamte Anwendung auf mögliche Schwachstellen hin zu untersuchen. Hierfür spezialisierte Profiler-Tools wie der Intel VTune Performance Analyzer, der Intel Thread Profiler oder PIX für Windows helfen dabei, entsprechende Engpässe aufzuspüren. Hierbei handelt es sich um zwei wesentliche Bereiche, in denen es immer wieder zu Leistungseinbußen kommt: Nicht-skalierender Quellcode und 3D-Runtimes und Treiber. Allein die zwei letztgenannten verbrauchen bei suboptimaler Programmierung 25 bis 40 Prozent der gesamten Prozessorkapazität. Hier eröffnet sich also eine Menge an Verbesserungsbedarf.

Darüber hinaus fressen Rendering-Prozesse sehr viel CPU-Bandbreite, je mehr an Spezialeffekten wie Regen oder Wind in der Anwendung stecken oder eine Zunahme an AI-Objekten zu verzeichnen ist. Daher ist der Programmierung und Parallelisierung von Render-Einheiten höchste Priorität einzuräumen.

So gilt speziell bei der effizienten Programmierung von multithreaded 3D-Inhalten, die auf DirectX-APIs basieren, vor allem eins: Vergessen Sie die Treiber nicht und fassen Sie häufig genutzte Routinen sinnvoll zusammen, vermeiden Sie das Reservieren zu großer Systemressourcen und ordnen Sie bestimmte Aufgaben nicht einem bestimmten Prozessor zu. Nur dann erstellen Sie optimierte DirectX-Anwendungen, die auf Multicore-Systemen optimal skalieren und zudem überflüssigen Quellcode und Treiber vermeiden.

Intel Parallel Studio setzt sich aus vier einzelnen Programmen zusammen, die entweder als Komplettpaket genutzt werden können oder aber jedes Tool für sich alleine.

Der Parallel Advisor untersucht bestehenden Sourcecode auf mögliches Parallelisierungspotenzial und schlägt bestimmte Routinen und Funktionen vor, mit deren Hilfe aus einfachen Programmen parallelisierte Anwendungen werden, die optimal auf Intel-Multicore-Plattformen laufen. Darüber hinaus analysiert der Advisor mögliche Programmkonflikte und nennt passende Lösungen.

Der Parallel Composer erlaubt die schnelle und relativ einfache Implementierung paralleler Funktionen und Programmschnipsel, die der Entwickler mithilfe fertiger Routinen und Bibliotheken in seinen bestehenden Sourcecode integrieren kann. Damit kann der Programmierer die bestmöglichen Ansätze für sein Projekt herausfinden und einsetzen.

Der Parallel Inspector fungiert als eine Art Debugger, der anhand der implementierten Multithread-Routinen und -Funktionen einen zuverlässigen und fehlerfreien Sourcecode garantiert. Hierfür spürt das Tool Fehler im Multithread-Code auf, die mit herkömmlichen Werkzeugen nur schwer zu finden wären. Der Inspector betreibt unter anderem intensive Ursachenforschung in Sachen Endlosschleifen, Deadlocks und anderen Fehlern.

Der Parallel Amplifier schließlich hilft beim Finetuning der parallelisierten Anwendung, indem er ungewollten und unvorhergesehen Singlethread-Code ermittelt, der sich als echter Flaschenhals in einer Multithread-Anwendung erweisen kann.