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

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!

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.

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!

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

Die ersten Multithread-Erfahrungen hat Nero mit seiner Brennsoftware vor vielen Jahren gemacht, was der Firma heute noch dabei hilft, neue Software-Titel für die aktuelle Hardware-Generation so zu schreiben, dass sie möglichst gut skalieren.

Nach einer ganzen Menge an marketinglastigen Infos wird’s endlich technisch. Zunächst geht es um die Frage, welchen Herausforderungen sich ein Entwickler gegenüber sieht, wenn er Multimedia-Software möglichst leistungsfähig schreiben will. Dazu gehört unter anderem Realtime-Encoding (und das natürlich parallel) – in möglichst vielen Datenformaten. Aber auch hoch komplexe Codecs, HD-Inhalte, große Datenmengen und DRM-/Sicherheitsaspekte stellen Herausforderungen dar.

Doch wie schafft es Nero, in Multicore-Dimensionen zu denken? Nun, hierfür sind laut Charly Lippoth neue Kenntnisse und ein neues Denken erforderlich. Dazu gehört beispielsweise die Erkenntnis, dass Funktionen möglichst gut auf den vorhandenen Prozessorkernen skalieren müssen.

Aber auch die Programmierung auf Maschinencode-Ebene hilft Nero beim Optimieren der Software, indem beispielsweise SSE-Befehle optimal eingesetzt werden. Ein weiterer Aspekt ist aber natürlich der Einsatz der richtigen Tools.

Ein gutes Beispiel für effizientes Multithreading sind Audio- und Videocodecs, bei denen es ein hohes Parallelisierungspotenzial gibt. Das beginnt beim Videoscaling und endet bei der Transformation von HD-Content in 2K- oder 4K-Inhalte.

Folgende Nero-Anwendungen sind parallelisiert: Move It, LiquidTV, Recode, 1080p-Wiedergabe und Mediamanagement.

Nero setzt auf Intel-Tools wie VTune Performance Analyzer und Parallel Inspector, mit deren Hilfe die aktuelle Bluray-Software verbessert werden konnte, da es in der Vergangenheit Probleme beim Synchronisieren von Daten und Threads gab.

Die abschließende Recode-Demo zeigt, was mit einer parallelisierten Anwendung möglich ist: HD-Videocontent lässt sich auf einem Core-i7-System in Echtzeit in ein portables Format konvertieren. Damit gelangen hochaufgelöste Inhalte innerhalb kürzester Zeit auf iPod, iPhone und Co.

Fazit: Nero lernt jeden Tag dazu und will und wird in Zukunft verstärkt auf Parallel Studio, Threading Building Blocks und die Task Parallel Library setzen. Und Entwickler und Programmierer kontinuierlich weiterbilden, für möglichst skalierende Anwendungen.

Dann durfte einer der Chefentwickler noch etwas zu seinen Erfahrungen mit Parallel Studio erzählen. Er zeigte sich sehr angetan von diesem Tool hinsichtlich des Aufspürens von Speicherproblemen zur Laufzeit. Aber: Der generierte Overhead ist nicht ganz trivial und muss noch verringert werden. Und an der Geschwindigkeit muss auch noch geschraubt werden. Aber darum nennt sich das Ganze auch noch “Beta” …

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 …

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!

In beiden Fällen wollten wir natürlich wissen, welche Anstrengungen unternommen wurden, um die Spieletitel zu parallelisieren. Tja, und heute haben wir Teil eins unserer Fragen zurückbekommen, und zwar von Crysis. Geantwortet hat der Director of Technology höchstpersönlich, Mister Mark Atkinson. Mark zeichnet übrigens verantwortlich für erfolgreiche Titel wie Burnout Revenge und Football Manager 2009, die er vor seiner Zeit bei Crytek mitentwickelt hat.

Software Dev Blog: Mit welchen Tools haben Sie Crysis für Multicore-Plattformen optimiert?
Mark Atkinson: Wir setzen im Wesentlichen eigene Tools ein, um den Quellcode unserer Spieletitel wie Crysis für Multicore-Plattformen zu optimieren. Aber auch externe Anwendungen wie der VTune Performance Analyzer kommen bei uns zum Einsatz. Dieser ist für uns vor allem wegen des Thread Profilers interessant, mit dessen Hilfe wir überprüfen können, in welchem Umfang und in welcher Qualität die Parallelisierung des Spieletitels gelungen ist.

Welche Hürden mussten Sie bei der Multicore-Optimierung überwinden?
Atkinson: Die wesentliche Arbeit bestand darin, die Game-Engine völlig umzukrempeln. Wir mussten nämlich große Teile des sequenziell programmierten Quellcodes parallelisieren, damit bestimmte Aufgaben wie die KI, Effekte etc. gleichzeitig ablaufen. Nur so konnten wir das optimale Spielerlebnis erreichen, das Crysis auszeichnet.

Welche Tipps würden Sie Entwicklern geben, wenn diese parallelen Programmcode schreiben wollen?
Atkinson: Die Hauptregel lautet: Erstelle fehlerfreien Sourcecode vom ersten Moment an. Denn parallel programmierte Anwendungen und Spiele lassen sich nur sehr aufwändig testen und debuggen. Daher sollte man von Anfang an darauf achten, dass sich erst gar keine Fehler in den Code einschleichen. Wir setzen hierfür erprobte Methoden, Bibliotheken und Hilfesysteme ein, die uns dabei unterstützen. Außerdem sorgen wir dafür, dass unsere Software-Entwickler bestens in Sachen Paralellprogrammierung ausgebildet sind. Denn nichts erfordert mehr Know-how als der Umstieg von der sequenziellen auf die parallele Programmierung.

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.