Intel Threading Challenge 2010: Von Katzen und Pokerkarten

Anfang Juni war es so weit: Intel startete seinen nächsten Parallel-Programmier-Wettbewerb, der sich aus zwei Phasen und insgesamt sechs Aufgaben zusammensetzt. Mittlerweile hat der Contest Phase 2, Aufgabe 3 erreicht, und wieder gibt es schöne Preise zu gewinnen.

Allerdings hat Intel vor den Gewinn das Denken gesetzt, und so kommt man auch bei der dritten Aufgabe der zweiten Phase nicht umhin, seine Parallelprogrammierkünste unter Beweis zu stellen. Dass es sich dabei um eine Aufgabe aus der Welt des Pokers handelt, ist (a) natürlich sehr amerikanisch und (b) sehr populär, da sich Poker schon lange größter Beliebtheit erfreut – und das nicht nur in den USA.

Dass es sich bei der zu Grunde liegenden Pokerart um die bei uns eher unbekannte Variante Pai Gow Poker handelt, spielt keine wirkliche Rolle. Alleine die Anzahl der zum Spiel gehörenden Karten (7 vs. 5 beim regulären Poker) variiert, der Rest ist wie immer. Die Aufgabe besteht darin, ein parallel programmiertes Tool zu entwicklen, das so schnell wie möglich heraus findet, mit welchen Kartenkombinationen ein einzelnen Spieler gegen die Bank gewinnen kann, welches das zweitbeste Blatt ist, das drittbeste, usw.

Die komplette Beschreibung und sämtliche Parameter findet ihr auf der Contestseite. Dort ist auch den Hinweis hinterlegt, dass zur Ermittlung des Gewinners die notwendige Zeit herangezogen wird, die das programmierte Tool verbraucht, bis es sämtliche Kartenkombinationen herausgefunden hat. Auf dieser Seite könnt ihr das Ergebnis eures Schaffens einreichen.

Ach ja: “Pai Gow” ist lediglich der Einsteiger-Wettbewerb des Intel Threading Challenge 2010. Beim Master-Challenge geht es um ein Spiel, das sich Katze und Hund nennt. Falls ihr also die echten Herausforderungen schätzt, solltet ihr dort auf jeden Fall auch mal vorbei schauen.

Für beide Aufgaben gilt, dass ihr sie bis spätestens 11. Oktober, 24:00 Uhr (PDT) eingereicht haben müsst. Und was ihr alles gewinnen könnt, erfahrt ihr auf dieser Seite. Und um das Lösen der Aufgaben ein wenig zu erleichtern, bietet Intel allen Teilnehmern Zugriff auf das Intel Manycore Testing Lab und die notwendigen Software-Tools. Damit kommen auch all diejenigen in den Genuss eines Multicore-Rechners, die keinen zuhause rumstehen haben.

Und jetzt: viel Spaß mit der 3. Aufgabe der 2. Phase der Intel Threading Challenge 2010!

Mit Intel Adivsor schrittweise parallel programmieren

Zurück von der großen Intel Entwickler-Konferenz – auch IDF (Intel Developer Forum) genannt – gibt’s hier Stück für Stück viele nützliche Infos und News aus der Welt des Parallel & Visual Computing. Soll heißen, dass ihr über all die Dinge etwas erfahrt, die ich mir in San Francisco angehört und angesehen habe. Also dann, viel Spaß 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…

Acht nützliche Tipps zum Parallelisieren

Aufmerksamen Lesern des Software Dev Blogs wird es nicht entgangen sein: es war hier in letzter Zeit ein wenig ruhiger, was mit vielen anderen Aktivitäten meinerseits zu tun hatte. Ich war viel unterwegs, hab viele neue Themen recherchiert und gesammelt, saß mit Leuten zusammen, etc. Und der Output wird sich sehen lassen können: Das reicht von Exklusivinfos direkt vom Intel Developer Forum in San Francisco bis hin zu neuesten Beiträge rund um das Thema Cilk und Co, die ich mit dem Kollgen Deilmann von Intel gemeinsam erarbeiten werde.

Den Anfang macht heute ein Online-Artikel des werten Kollegen Edmund Preiss, der es sich mal wieder zur Aufgabe gemacht hat, die Parallelprogrammierung ein wenig näher zu begutachten. Herausgekommen sind acht sehr nützliche Tipps, die ich hier zusammenfassen will. Den kompletten Beitrag findet ihr auf elektroniknet.net.

Tipp 1: In parallelen Strukturen denken und entwickeln — Hiefür bietet sich für C++-Entwickler beispielsweise das Intel-Tool Parallel Advisor an, das dabei hilft, in einem seriellen Programm parallel Strukturen aufzuspüren. Hierzu gibt es nächste Woche mehr Infos direkt vom IDF, die ich mit vielen Bildern garnieren werde.

Tipp 2: Höhrere Abstraktionsgrade erlauben thread-sichere Programme — Hierfür bieten sich spezielle Bibliotheken an, aber auch Programmiermodelle wie OpenMP oder Intel Threading Building Blocks. Ganz neu am Start in diesem Zusammenhang sind die Intel Array Building Blocks. Auch hierzu gibt es nächste Woche dedizierte Infos.

Tipp 3: Denke und programmiere in Tasks, nicht in Threads — Dieser Tipp hilft, die Skalierbarkeit auf mehreren Prozessorkernen deutlich zu verbessern

Tipp 4: Arbeite mit so wenig Locks wie möglich, aber mit so vielen wie nötig — Hier geht es um Data Races, die beim Umgehen von Locks entstehen können. Und mit Tools wie dem Intel Parallel Inspector kann man mögliche Data Races und Dead Locks identifizieren lassen.

Tipp 5: Skalierbare Speicker-Allokatoren helfen, Speicherzuweisung bei parallelen Programmen zu optimieren.

Tipp 6: Erhöhe die parallele Auslastung, um den seriellen Anteil an Code zu verringern — Dies hat mit der Erkenntnis zu tun, dass Anwendungen nur mit ihrem Anteil an parallelen Ausführungen signifikant schneller werden. Daher sollte man mit den passenden Tools nach Programmbereichen suchen, die sich gut multithreaden lassen. Hierzu gehören beispielsweise Schleifenkonstrukte.

Tipp 7: Teste parallelisierte Programmabschnitte im seriellen Modus auf mögliche Bugs hin — Hierzu gibt es zwei Möglichkeiten: Entweder das “Abschalten” parallelisierter Codeabschnitte mithilfe bestimmter Schalter oder der Einsatz der Intel Parallel Debugger Extensions, die Teil des Intel Parallel Composer sind.

Tipp 8: Software-Tools helfen, während der einzelnen Entwicklungsschritte (Design, Kompilieren, Debuggen, Verifikation und Leistungsverbesserung), die richtigen Dinge zu tun. Hierzu gehört die Entwicklersuite Intel Parallel Studio, die Entwicklern nativ programmierter Programme genau dabei hilft.

Das war die GDCE 2010: Videointerviews und mehr, Teil 3

Sodala, nachdem Teil 1 und Teil 2 der GDCE-2010-Rückschau draußen sind, folgt jetzt das dritte und letzte Kapitel meiner Trilogie in Sachen Spieleentwicklung. Den Abschluss soll ein Dreiteiler bilden (sic!), der sich mit der Analysetool-Suite Intel Graphics Performance Analyzers beschäftigt.

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.

Das war die GDCE 2010: Videointerviews und mehr, Teil 2

Wie ich gestern versprochen habe, folgt heute der zweite Teil des großen GDCE-2010-Rückblicks. Waren gestern die Havok Physics Engine, das Multithreaden von Games mithilfe von DirectX 11, Netbook-Games und Intel GPA dran, folgen heute Erkenntnisse rund um die nächste Version von Intel GPA, um das Parallelisieren von Spielen mithilfe von Intel TBB und einer Task-Stealing Engine der Marke Eigenbau.

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 war die GDCE 2010: Videointerviews und mehr, Teil 1

Letzte Woche war ich ja auf der Game Developers Conference Europe, und daher ist es jetzt an der Zeit, eine große Rückschau zu halten. Das geschieht in drei Teilen, damit ihr euch das Ganze Stück für Stück einverleiben könnt. Viel Spaß beim Angucken der Videos, die wir an den drei Tagen in Köln gedreht, geschnitten und online gestellt haben.

Am ersten Tag ging es gleich mal sehr animationsmäßig los und wir hatten die Gelegenheit, uns die Havok Physics Engine näher anzusehen, mit deren Hilfe Spieleentwickler recht einfach und schnell bestimmte Effekte in ihre Games einbauen können. Dazu gehören Dinge wie Deformationen, berstende Gegenstände, etc. Und auch vollanimierte Kleidungsstücke lassen sich mit Havok generieren, ohne dass der Entwickler genau wissen muss, wie das funktioniert. Dass es funktioniert, belegen die zugehörigen Videos sehr gut.

Das Thema Spiele beschäftige uns natürlich weiterhin (sic!). So konnten wir mit Jerome Muffat-Meridol von Intel über seine Techsession reden, in der es um das Thema Multithreading von 3D-Spielen mithilfe von DirectX 11 ging. Dabei zeigte er anhand der so gennanten Nulstein-Demo, dass sich Spiele sehr gut parallelisieren lassen, wenn man den richtigen Taskscheduler und DirectX 11 für die einzelnen Phasen beim Erzeugen von 3D-Bildern dazu einsetzt, das ganze System so gut wie möglich zu parallelisieren. Und das skaliert dann problemlos auf 12 Threads, ohne dass der Entwickler große Dinge vollführen muss.

Weiter ging’s dann mit einem ganz anderen Thema, das auf dem IT-techBlog sehr viel besser aufgehoben wäre: Netbook-Games. Hierzu zerrten wir Leigh Davies vor die Kamera, um ihm drei schlaue Fragen zu stellen. Dabei kam heraus, dass Leigh in seiner Session etwas darüber verraten hatte, wie sich Spiele für Netbooks verkaufen lassen und wie man Netbook-Games für die GPU und CPU optimieren kann.

Natürlich durfe auch der Hinweis nicht fehlen, dass sich Netbooks weiterhin gut verkaufen und dass Intel bis zum Jahr 2013 mit zirka 140 Millionen verkauften Mininotebooks rechnet. Es ging außerdem auch um technische Aspekte wie die eingeschränkte Auflösung (1024*600) und die daraus resultierenden Konsequenzen. So rät Leigh zum Einsatz von Icons statt Text. Darüber hinaus sollte man sich als Spieleentwickler klar machen, dass ein Netbook wegen der guten bis sehr guten Akkulaufzeiten und des geringen Gewichts in höchstem Maße mobil ist. Auch das gilt es beim Gamedesign zu berücksichtigen.

Aber nicht nur Spiele für tragbare Computer standen bei Intel auf de GDCE 2010 auf dem Programm. Auch die neuesten Version des Analysetools Intel Graphics Performance Analyzers wurde vorstellt, und hierum kümmerte sich Steve Hughes von Intel, der uns ein bisschen was über die neuen Features von Intel GPA 3.0 erzählte, wie man damit Flaschenhälse und andere Verklemmungen in 3D-Spielen findet und wie Entwickler die Toolsuite optimal für ihre Zwecke einsetzen können. Besonders begeistert zeigte er sich von der neuen Platform View, die systemübergreifend zeigt, wie gut ein Spiel auf einer Multicore-Maschine skaliert.

So, das war`s erstmal, Teil 2 und Teil 3 folgen morgen. Darin wird es um die nächste Version von Intel GPA gehen, um das Parallelisieren von Spielen mithilfe der Intel TBB, um einen selbstgezimmerten Taskscheduler mit Taskstealing und um eine Live-Demo, die anhand von drei Teilen genau zeigt, wie sich Intel GPA einsetzen lässt.

GDCE 2010: Erster Tag mit Intel GPA, Netbook-Games und Havok Physics-Engine

Der erste Tag hier auf  der Game Developers Conference Europe 2010 ist schon wieder fast Geschichte. Daher folgt eine Zusamenfassung der ersten Sessions, Erkenntnisse und der Havok-Demo.

Die erste Intel Techsession hielt Steve Hughes, der über Intel Graphics Performance Analyzers sprach. Diese Toolsuite hilft Entwicklern, ihre Spiele und Anwendungen zu analysieren und mögliche Flaschenhälse und andere nervige Dinge aufzuspüren und zu eliminieren. Steve sprach auch über die neuen Features vin Intel GPA 3.0, zeigte, wie sich die drei Werkzeuge (System Analyzer, Frame Analyzer, Platform View) richtig einsetzen lassen und wie man mit diesen Tools Veränderungen an einzelnen Frames unmittelbar sehen kann

Darüber hinaus haben wir gelernt, dass Intel GPA ein SDK und ein Capture-Tool umfasst, dass Intel GPA als Client-Server-Anwendung läuft, um die Testplattform so wenig wie möglich mit den notwendigen Berechnungen zu belasten und dass man mit Intel GPA einfach und schnell ganz tief in sein Spiel blicken kann.

Techsession Nummer zwei hielt Leigh Davies, der ebenfalls für Intel arbeitet. Sein Vortrag nannte sich “Building Games for Netbooks” und war randvoll mit interessanten Erkenntnissen wie diesen:

• Ad-hoc-Gaming für Netbooks ist mit dem Intel Laptop TDK ziemlich einfach.
• So aktiviert man die APIs des Intel Laptop TDK.
• So maximiert man die Rechenleistung des Intel Atom Prozessor mithilfe von Threading und SSE-Befehlen.
• Diese Vektorisieringsoptionen können für den Intel Atom-Prozessor angewendet werden.
• Mit den richtigen Compiler-Einstellungen optimiert man seine Spiele für die Intel Atom-CPU.
• Und vieles mehr

Darüber hinaus hatten wir die Gelegenheit, mit den Jungs von Havok zu reden, die sich den Demostand mit Intel teilen. Zu diesem Zweck haben wir unsere Videokamera aufgebaut und uns die Havok-Demo zeigen lassen, die aus drei Teilen besteht: die Havok Physics im Allgemeinen, zu “Zerstörungszwecken” und für das Rendern von Kleidung und Ähnlichem in Echtzeit. So, dann einfach nur auf den jeweiligen Link geklickt und das Video angeschaut. Viel Spaß dabei!

GDCE 20X: Games mit DirectX 11 und Intel TBB parallelisieren

Genau in drei Tagen beginnt die Game Developers Conference Europe 2010 in Köln. Dort werden von Montag bis Mittwoch Spiele-Entwickler Dutzende von Techsessions besuchen. Vier dieser technischen Präsentationen werden von Intel Software-Ingenieuren gehalten, die eine Menge interessanter Dinge rund um das Thema Spiele-Programmierung und -Entwicklung zu erzählen haben. Über zwei dieser Vorträge habe ich bereits ausführlicher gebloggt (Session #1 und Session #2), und heute folgt eine Vorschau der Dienstag-Sessions. Diese handeln vor allem davon, wie man 3D-Spiele parallelisiert, damit sie optimal auf Mehrkernprozessor-Systemen laufen.

Der erste Vortrag am Dienstag dauert von 9:00 bis 9:50 Uhr, wird von Jerome Muffat-Meridol gehalten, und trägt den originellen Titel “UFO Invasion: DX11 and Multicore to the Rescue”. Der Tenor seiner Präsentation lautet: Mit welchen Bordmitteln von DirectX 11 lassen sich 3D-Games so optimieren, dass sie parallel auf Multicore-Maschinen ausgeführt werden. Jeromes Techsession findet im 4. Stock im Nördlichen Sitzungszimmer statt.

Jerome wird unter anderem darüber reden, wie sich Drawcalls gleichzeitig auf mehrere Threads verteilen lassen, was eure Spiele besser und effizienter parallelisiert. Und da Sehen besser als nur Hören ist, hat Jerome eine erst kürzlich veröffentlichte Demo-Game-Engine dabei, mit deren Hilfe Multicore-optimierte Spiele implementiert werden können. Diese Game-Engine nennt sich Nulstein und verteilt den vorhandenen Spielecode task-basiert auf die vorhandenen Ressourcen. Das sorgt für ein optimal ausgewogenes Spieleerlebnis, da sämtliche vorhandenen CPU- und GPU-Ressourcen optimal ausgenutzt werden.

Die zweite Techsession hält der geschätzte Kollege Mario Deilmann, dessen Vortrag von 14:20 bis 15:10 Uhr geht, wiederum im Nördlichen Sitzungszimmer stattfindet und von den Intel Threading Building Blocks handelt. Mario wird dabei zeigen, wie sich mit dieser Runtime-Bibliothek Thread-sichere Spiele programmieren lassen, und zwar mithilfe von Lambda-Funktionen und anderen Parallelkonstruktionen. Darüber hinaus geht Mario auf diverse Intel-Tools ein, mit denen sich seriell und parallel programmierte Applikationen analysieren lassen. Auf diesem Wege sollen Laufzeit-kritische Engpässe gefunden und möglichst eliminiert werden.

Mario wird ebenfalls auf die wichtigsten Features der aktuellen Version der Intel TBB näher eingehen. Dazu gehören der verbesserte Taskscheduler und die effizientere Speicherverwaltung, der verbesserte Support von Lambda-C++0x-Funktionen und die erhöhte Kompatibilität hinsichtlich Visual Studio 2010 und dessen neuen Komponenten.

Die gute Nachricht: Ihr lernt nicht nur interessante Dinge von Steve, Leigh, Jerome and Mario, sondern wir werden vor Ort auch darüber twittern und bloggen. Und für weitere Infos zu ihren Vorträgen werden die Jungs vor unsere Kamera treten, um uns und euch mit tiefergehenden Details zu versorgen. Also, man sieht sich – entweder live in Köln oder hier oder auf dem IT-techBlog.

GDCE 2010-Techsession: So setzt man Intel Graphics Performance Analyzers richtig ein

Wie ich gestern gebloggt habe, werden wir nächste Woche auf die Game Developers Conference 2010 fahren, die vom 16. bis 18. August 2010 stattfindet. Und wie üblich werden wir wieder voll bepackt sein mit allerlei Hardware wie unseren Notebooks, der Videokamera, den Scheinwerfern, Mikros und so manchem mehr. Unsere Mission: Live-Twittering, Live-Blogging und Live-Interviewing von einem der größten Entwickler-Events, das die Gaming-Industrie vorzuweisen hat.

Natürlich werden wir nicht alleine in Köln herumspringen, da sich auch ein paar Intel-Leute dort aufhalten werden, um coole Software-Demos (sprich Tools) auf dem Intel-Stand zu zeigen und darüber hinaus über verschiedene Dinge in Form von Techsessions zu reden. Und wie ich ja gestern versprochen habe, gibt es heute ein paar weitere Infos, was ihr von den Intel-Vorträgen auf der GDCE 2010 erwarten könnt.

Die erste Präsentation findet am Montag um 10:10 Uhr statt, dauert 50 Minuten, wird von Steve Hughes gehalten und trägt den Titel “PC Profiling Made Easy with Intel Graphics Performance Analyzers”. Steve ist Senior Application Engineer bei Intel und seiner Techsession kann man im Nördlichen Sitzungszimmer im vierten Stock beiwohnen.

Sein Votrag beschäftigt sich unter anderem mit den Hauptmerkmalen der Toolsuite Intel Graphics Performance Analyzers (IGPA) und wie man damit Echtzeit-Analysen von 3D-Spielen durchführen kann, ohne die Runtime-Engine unnötig aufzublasen. Zu diesem Zweck bietet IGPA diverse Profiling-Ansichten, mit denen die Leistungsdaten des gesamten Systems erfasst werden können. Aber auch von Visualisierungstools, einem Frame-Analyzer, einem Debugger und einem Multithreading-Testtool wird die Rede sein.

Während seiner Präsentation wird Steve also zeigen, wie man mithilfe von IGPA eine Menge Zeit sparen und nervige Flaschenhälse sowohl auf CPU- als auch auf GPU-Seite finden und eliminieren kann. Das bedeutet für euch als Entwickler, dass ihr euch mehr um euren Code und weniger um die Fehleranalyse und deren Behebung kümmern müsst. So könnt ihr mit IPGA zum Beispiel recht einfach herausfinden, wieviele Drawcalls pro Szene stattfinden, wieviel Bandbreite die eingesetzten Texturen beanspruchen und wieviel Rechenzeit die verschiedenen Shader vom Gesamtsystem abzwacken.

So ist es bestimmt eine gute Idee, Steves Vortrag auf der GDCE 2010 auf keinen Fall zu verpassen. Wenn er auf dem Intel-Stand sein wird, gibt er euch bestimmt auch eine kostenlose IGPA-Demo. Und was die anderen Intel-Leute auf der GDCE 2010 erzählen werden, erfahrt ihr morgen.

GDCE 2010: Techsession-Infos und mehr

In knapp einer Woche, genauer gesagt am Montag, den 16. August, beginnt in Köln eine der größten Entwicklerkonferenzen für Spiele-Programmierer, die Game Developers Conference Europe 2010. Mit von der Partie ist auch dieses Mal wieder Intel, genauer gesagt die Software-Abteilung, die sich den ganzen Tag Gedanken macht, wie Software-Titel externer Entwickler besonders gut auf einem PC mit Intel-Prozessor laufen.

Um das Thema Software-Optimierung für Game-Entwickler optimal darstellen zu können, betätigt sich Intel als einer der Hauptsponsoren dieses Mega-Events, was zur Folge hat, dass man diverse Intel-Vorträge besuchen kann, wenn man möchte. Zudem wird Intel auf der GDCE 2010 mit einem eigenen Stand vertreten sein, auf dem man eine Menge über diverse Entwicklerwerkzeuge wie die Intel Graphics Performance Analyzers lernen kann – Live-Demo inklusive.

Die Vorträge, die am Montag und Dienstag stattfinden werden, sind derer vier. Der Zeitplan sieht folgende Techsessions vor:

• Montag, 10:10 – 11:00 Uhr: PC Profiling Made Easy with Intel Graphics Performance Analyzers von und mit Steve Hughs, der wohl auch wieder die Live-Demo am Intel-Stand vorführen wird.

• Montag, 14:20 – 15:10 Uhr: Building Games for Netbooks von und mit Leigh Davies

• Dienstag, 9:00 – 9:50 Uhr: UFO Invasion: DX11 and Multicore to the Rescue von und mit Jerome Muffat-Meridol

• Dienstag, 14:20 – 15:10 Uhr: Turbo Charge your Game with Intel Threading Building Blocks von und mit Mario Deilmann

Klar, dass die Intel-Experten vor und nach den Vorträgen und später am Stand euren Fragen Rede und Antwort stehen werden. Kommt also Zuhauf in die Sessions und auf den Intel-Stand während der GDC2010. Es lohnt sich!

Ach ja, und wen es interessiert, was sich hinter den einzelnen Vorträgen verbirgt, sollte hier morgen wieder vorbei kommen. Und übermorgen. Und am Freitag. Und natürlich nächste Woche, wenn wir live vor Ort sind und twittern, bloggen und Videointerviews führen und diese auf Youtube stellen. So, watch this space!

Baue eigene 3D-Games – for free und Multicore-optimiert

Dass Intel die Software-Gemeinde schon seit vielen Jahren mit Entwicklertools, Know-how und einer eigenen Gemeinde unterstützt, ist ja nichts Neues. Dass man aber als Spiele-Entwickler die geballte Kraft des UDK (Unreal Developer Kit) kostenlos bekommt, ist schon etwas ganz Besonderes. Finde ich.

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…

Video: So lassen sich Spiele mit Intel GPA optimieren

Zugegeben, die Develop 2010 ist mittlerweile über eine Woche alt, und doch tauchen immer wieder nützliche Infos rund um das Thema Spieleprogrammierung auf. So auch heute auf dem SoftTalk Blog, auf dem ich ein interessantes und informatives Video gefunden habe. In diesem Fast-Fünfminüter spricht Leigh Davies neben seinem Job bei Intel vor allem über die Toolsuite Intel Graphics Performance Analyzers und wie sich damit PC-Spiele verbessern und optimieren lassen. So lernt man anhand des Videos folgende Dinge:

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

Infos zur Spieleprogrammierung für Netbook und Co.

Erst letzte Woche habe ich über die Develop 2010 berichtet. Auf dieser Spiele-Entwickler-Konferenz, die im englischen Brighton stattfand, ging es in rund 80 Techsessions um das Thema 3D-Games und wie Software-Entwickler davon profitieren können. Zu den Sponsoren gehörte unter anderem Intel, die natürlich auch eigene Sessions abhielten.

Über eine dieser Sessions habe ich letzten Freitag schon berichtet, und heute erreichte mich die Nachricht, dass es zu den Intel-Aktivitäten eine eigene, kleine Webseite gibt, auf der sich weitere Infos zur Develop 2010 befinden. Dazu gehören unter anderem die Präsentationen in Form von Folien, die die Vorträge kurz und knackig abbilden. Hierunter sind folgende Themen:

1. Building Games for Netbooks
2. PC Profiling Made Easy with Intel Graphics Performance Analyzers (Folien)
3. Vectors of Performance in Gaming (Folien)

Zu Nummer eins habe ich selber schon das ein oder andere gesagt und sogar schon einen eigenen Vortrag gehalten. Zu Nummer zwei gibt es hier auf diesem Blog ebenfalls weiterführende Infos und einen Videobeitrag. Tja, und Nummer drei handelt von solch technischen Dingen wie SIMD, SSE4, Intel AVX und einiges mehr.

Also, ihr Spieleentwickler da draußen, besorgt euch die Präsentationen und schaut, wie ihr das Ganze in eure eigene Arbeit einfließen lassen könnt!

Wie sich 3D-Spiele optimieren lassen

Ja doch, die Fußball-WM 2010 ist Geschichte, hat einen neuen Weltmeister gekürt und England war mal wieder verdammt früh Zuhause. Das hat aber den Kollegen Leigh Davies von Intel UK nicht davon abgehalten, seine Techsession anlässlich der Develop 2010 mit einem Fußballspiel-Beispiel zu eröffnen.

Er hatte nämlich seinerzeit mit einem echten Problem zu kämpfen: Warum ist dieses Soccer-Game, das er gerade entwickelte, nur so langsam? Also haben er und seine Kollegen nach und nach alles ausgeblendet, was auszublenden war: Stadium, Spieler, etc. Bis einer von den Programmierern auf die Idee kam, sich den Ball mal genauer anzusehen, und siehe da: Das runde Leder (das ja eigentlich gar nicht rund ist) bestand aus 5.000 Polygonen! Und das in einer Zeit, als sich 3D-Objekte eher aus 300 Polygonen zusammensetzten. Tja, damit war der Schuldige also gefunden (wie so oft der Ball).

Und, was lehrt uns das? Dass es beim Optimieren von 3D-Spielen oft mit dem Teufel zugeht und man auf den ersten und zweiten Blick gar nicht erkennt, warum bestimmte Spielsequenzen ruckeln oder auf einem Netbook beispielsweise gar nicht laufen. Wie gut, dass es mittlerweile für solche Herausforderungen Tools gibt wie die Intel-Suite Graphics Performance Analyzers.

Das Gute an Intel GPA ist ihre Flexibilität: Egal, ob man sein 3D-Spiel auf einem Core-i3- oder i5-System mit integrierter Grafik testen will oder gar auf einer diskreten Grafikkarte – das Toolset unterstützt beide Spielarten. Intel GPA besteht übrigens aus drei Teilen: System Analyzer, Frame Analyzer und Platform View. Mit dem System Analyzer lassen sich grundlegende Dinge wie die Framerate, Prozessorauslastung, Vertex-Lock-Zeiten und einiges mehr herausfinden.

Mit dem Frame Analyzer begibt man sich dann auf die eingegrenzte Fehlersuche, indem man beispielsweise eine spezielle Szene herausgreift und diese genau analysieren lässt und somit den Fehler (hoffentlich) findet. Und mithilfe von Platform View lernt man alles über die im Hintergrund laufenden Threads, die sich zur Laufzeit ergeben. Dies schärft das Verständnis für das Spiel “unter der Haube” und erlaubt eine genaue Analyse, wo es klemmen könnte. Hierfür muss man allerdings ein paar Zeilen Quellcode einfügen, im Gegensatz zum System und Frame Analyzer.

So, und wer jetzt mehr wissen will über Intel GPA, dem sei dieser englischsprachige Artikel empfohlen oder dieses Video von der GDC09. Oder ihr wartet auf unsere Berichterstattung live von der GDC 2010, die vom 16. bis 18. August in Köln stattfinden wird. Dort wird Intel GPA ebenfalls vertreten sein.

Spiele-Entwickler auf der GDC 2010: Start your engines!

Heute habe ich meine Presseakkreditierung in Sachen GDC 2010 beantragt. Und da ich dann schon mal so schön beim größten europäischen Entwicklerevent der Gaming-Branche bin, werde ich natürlich mal wieder darüber berichten, was sich  in Köln vom 16. bis 18. August 2010 so alles tut.

Also, um es gleich (wieder) klar zu machen: Ich fahre wie jedes Jahr für Intel auf die GDC, um vor Ort alle relevanten Themen abzubilden, die aus Intel-Sicht wichtig sind. Zu diesem Zweck begebe ich mich nicht alleine nach Köln, sondern habe wie so oft Tom Papadhimas dabei, der mir seine Video-Expertise zur Verfügung stellen wird. Soll heißen, dass wir drei Tage lang interessante und bekannte Leute vor die Kamera holen, ihnen ein Mikro unter die Nase halten und ihnen schlaue Fragen stellen werden. So wie immer halt.

Dieses Jahr schickt Intel wieder einen Schwung eigener Leute nach Köln, die unter anderem über folgende Dinge reden werden:

• Leigh Davies wird zeigen, wie sich Spiele für Netbooks konzipieren und entwickeln lassen. Hierzu gibt es diverse Tools, eine komplette Community und sogar einen eigenen App Store, wo man das Netbook-Game einstellen und verkaufen kann.

• Steve Hughes demonstriert während seiner Techsession, wie sich mithilfe der Tool-Suite Intel Graphics Performance Analyzer Flaschenhälse und ähnliche Dinge innerhalb eines Spiels aufspüren und eliminieren lassen. Darüber hinaus erlaubt Intel GPA das Optimieren von 3D-Games für unterschiedlichste Plattformen – vom Netbook bis Highend-Laptop.

• Mario Deilmann hat die Intel Threading Building Blocks im Gepäck und wird zeigen, wie sich mit dieser Threading-Bibliothek hochkomplexe Spiele at-its-best optimieren lassen. Natürlich geht es dabei auch um die neuen Features der Version 3.0.

• Jerome Muffat-Meridol kümmert sich verstärkt um das Thema DirectX 11 und warum es mit der Grafik-API von Microsoft einfacher wird, parallel ablaufende Spiele zu programmieren, und das rein mit DirectX-Bordmitteln.

Ja, diese Jungs werden wir auf jeden Fall zu ihren Techsessions vor Ort befragen und herausfinden, wie Spiele-Entwickler davon profitieren können. Und natürlich gibt es auf diesem Kanal in den nächsten Wochen mehr und mehr Infos rund um die GDC 2010.

Artikelempfehlungen rund um Parallelprogrammierung

Heute gibt es auf dem Sofware Dev Blog vier Artikelempfehlungen, die sich mit dem Thema Multicore und Parallelprogrammierung beschäftigen. Die Beiträge sind stellenweise zwar nicht mehr ganz taufrisch, haben aber an Aktualität nichts eingebüßt. Im Gegenteil.

Der Beitrag Programmiermodelle für moderne Mehrkernarchitekturen geht ganz rudimentär auf die verschiedenen Ansätze ein, wie aus sequentiell programmierten Anwendungen parallel ablaufende Applikationen werden. Dabei zeigt der Autor die Unterschiede auf, die es unter anderem bei OpenMP, Thread-Bibliotheken, Java, C# zu berücksichtigen gilt. Ein guter Einstieg in die Welt der Parallelprogrammierung.

Der zweite Artikel setzt dort an, wo der erste quasi aufhört: bei einem dieser Modelle, und zwar OpenMP. Dabei will der Autor allerdings keine umfängliche Darstellung von OpenMP leisten, sondern den praktischen Nutzen darstellen. Dies geschieht mithilfe vieler nützlicher Beispiele. Und natürlich werden auch mögliche Stolperfallen wie Data Races besprochen.

Der dritte Artikel Parallelisierung mit der POSIX Thread Bibliothek beschäftigt sich mit einem Thema, das hochkomplex, aber auch sehr fundamental ist: Wie multithreade ich eine Anwendung mithilfe plattformunabhängiger Pthreads? Dieses Konzept ist zwar nicht mehr State-of-the-Art, bietet dafür aber die Möglichkeit, hochperformante, parallel ablaufende Anwendungen zu programmieren. Und das Verständnis rund um das Thema Parallelprogrammierung wird mithilfe der Pthread-Kenntnisse ebenfalls geschärft.

Tja, und auf den vierten Artikel habe ich bereits letzte Woche aufmerksam gemacht. Na dann, viel Spaß beim Lesen!

Parallelprogrammieren lernen mit Schach

Der werte Kollege Deilmann von Intel hat mir ein paar Internetlinks zukommen lassen, deren Inhalte sich mit dem Thema Parallelprogrammierung beschäftigen. Ein Beitrag hierzu ist auf den ersten Blick zwar ziemlich oberflächlich, bietet aber auf den zweiten Blick viele nützliche Infos zum Thema Multicore und Multithreading. In Form eines 34-seitigen pdfs wird nämlich das N-Queens-Problem detailliert dargestellt und gezeigt, wie sich dieses per Parallelprogrammierung lösen lässt.

Zur Erinnerung: das sogenannte “Damenproblem” stammt aus der Mathematik und beschäftigt sich mit der Frage, wie viele Damen auf einem Schachbrett so aufgebaut werden können, dass sie sich gemäß der Schachregeln nicht gegenseitig schlagen können. Auf einem 8×8-Schachbrett gibt es übrigens 12 eindeutige Lösungen.

Nur, wie lässt sich das für eine größere Zahl n berechnen, und wie geschieht das auf einem Parallelrechner möglichst schnell? Genau damit beschäftigt sich der pdf-Workshop, der sehr anschaulich und anhand vieler Codebeispiele mögliche Ansätze und Konzepte miteinander vergleicht und natürlich auch verrät, welche Lösung die beste ist, wenn man solche Probleme möglichst elegant und parallel lösen möchte.

Der Download ist kostenlos und jedem Einsteiger in die Parallelprogrammierung sehr zu empfehlen.

Infos aus erster Hand zu Cilk

Wie ich ja kürzlich per Twitter vermeldet habe, saß ich am Dienstag mit Mario Deilmann von Intel beisammen, um über ein paar mögliche Themen für das Software Dev Blog zum Thema Multicore-Programmierung zu reden. Und so haben wir diverse Themen evaluiert und identifiziert, und als erstes Ergebnis veröffentliche ich heute ein paar Infos zu Cilk, die mir Mario in mein iPhone diktiert hat. Und so gibt es dann nach und nach zu Cilk und den anderen Themen weitere interessante Informationen.

Die Idee von Cilk ist recht einfach: Man erhält ein serielles Programm, wie man das schon von OpenMP kennt. Allerdings kann das mit OpenMP “unterwandert” werden, indem man Abhängigkeiten in den Code einbaut. Bei Cilk hingegen werden die zu parallelisierenden Codeteile einfach mithilfe bestimmter Spawn-Konstrukte ausgelagert. Zudem können die so parallelisierten Abschnitte wieder serialisiert werden, indem man die Spawn-Befehle einfach wieder aus dem Code herausnimmt. Daneben gibt es ein weiteres Cilk-Konstrukt, das mittels einer for-Methode Schleifen parallelisiert.

Das Tolle an Cilk ist der zugeghörige Scheduler, der sehr schlau ist und task-orientiert arbeitet, und nicht wie bei OpenMP thread-basiert. Dabei werden stets möglichst viele Tasks an den Scheduler übergeben, der diese mit einem intelligenten Algorithmus auf die vorhandenen Thread-Ressourcen verteilt. Der Scheduler ist übrigens derart skalierend, dass auch große Rechensysteme optimal ausgenutzt werden.

So skalierte ein cilk-optimiertes Schachprogramm auf einem Rechner mit 512 Kernen so gut, dass es den dritten Platz in einem großen Schachturniert belegte. Der Trick des Cilk-Schedulers besteht übrigens darin, dass die Tasks per Zufall auf die Threads verteilt werden und nicht nach “menschlichen” Kriterien. Ach ja: Das Work Stealing hat seinen Ursprung im Cilk-Scheduler und wurde sukzessive in die Microsoft-Scheduler eingebaut.

Daneben muss mit Cilk nicht darauf geachtet werden, dass die zu parallelisierenden Aufgaben (Tasks) logisch angeordnet sind. Einzige Voraussetzung für eine cilk-basierte Parallelisierung ist die Unabhängigkeit der Tasks zueinander, so dass jeder Task eine Spawn-Methode zugewiesen werden kann. Darüber hinaus dürfen die jeweiligen Codeabschnitte nicht von globalen Variablen abhängen beziehungsweise diese nicht modifizieren. Ansonsten bekommt man es ganz leicht mit Data Races zu tun.

Allerdings ist zu berücksichtigen, dass es mit Cilk wie bei OpenMP, TPL und PPL vor allem um eine Lastverteilung geht, und nicht um eine Verteilung von Funktionalitäten auf die vorhandenen Ressourcen.

Schön an Cilk ist auch die einfache Handhabung: Außer den beiden Spawn- und For-Konstrukten muss man nichts lernen, sodass selbst ungeübte C- und C++-Entwickler Cilk ziemlich schnell einsetzen können. Das Gute an Cilk ist auch seine Vorhersehbarkeit: Sobald das cilk-optimierte Programm vorliegt, kann man anhand der gegebenen Parameter genau berechnen, was die Parallelisierung in Sachen Rechenleistung bringen wird.

Eine Besonderheit an Cilk sind die sogenannten Hyperobjects, mit denen ein parallelisierter Codeabschnitt seine eigene Sicht auf globale Variablen bekommt. Soll heißen, dass jeder Thread seinen eigenen Zugriff auf die globalen Variablen erhält, ohne diese zu verändern, so dass es nicht zu Data Races kommen kann. Dabei wird das Ganze lock-frei realisiert, da für jeden Thread eine eigene Speicherzelle angelegt wird, deren Inhalte am Schluss wieder zusammen geführt werden, so dass das richtige Ergebnis in der globalen Variable steht. Praktisch an Hyperobjects ist auch die Tatsache, dass man eigene anlegen kann. Damit ist Cilk ein ganzes Stück flexibler als OpenMP oder TBB.

Review: Multicore-Programmierung auf den dotnetpro.powerdays, Teil 2

Zugegeben, die dotnetpro.powerdays sind schon wieder eine Woche her, was mich aber nicht davon abhalten soll, den zweiten Teil meiner Rückschau zu veröffentlich. Sorry Leute, ich bin einfach nicht früher dazu gekommen. War ziemlich viel los seitdem.

Nach der Keynote-Session von Mario Deilmann (mit dem ich übrigens gestern zusammen saß, neuer Geschichten wegen) waren Bernd Marquardt und Volker Jungbluth an der Reihe, die eine Menge über PPL, TPL und OpenMP zu erzählen hatten.

Bernd begann mit seiner PPL-Session, die sich mit der Parallel Pattern Library beschäftigte. PPL richtet sich an native Programmierer und soll die Parallelprogrammierung deutlich vereinfachen, da sich Entwickler nicht um das Verteilen des parallelisierten Quellcodes auf die zugehörigen Threads kümmern müssen. Dabei sollte man laut Bernd aber trotzdem sicher stellen, dass der seriell erstellte Code fehlerfrei läuft, bevor man sich ans Parallelisieren macht. Ach ja: Die PPL lässt sich nur mit Visual Studio 2010 einsetzen.

Die PPL besteht vor allem aus thread-sicheren Algorithmen, Containern, Objekten und der Task-Parallelisierung. Ein wesentlicher Bestandteil dabei sind sogenannte Lambda-Funktionen, mit denen Code als Parameter in einem Methodenaufruf übergeben werden kann. Dies geschieht mithilfe spezieller Funktionen wie parallel_for() und parallel_for_each(). Besonders interessant ist die Funktion parallel_invoke(), mit der sich bis zu 10 Lambda-Funktionen parallelisieren lasssen, die allerdings alle möglichst gleich lang sein sollten.

Es gibt darüber hinaus Methoden wie try() und throw(), mit denen parallele Schleifen unterbrochen werden können. Und mit der combinable-Klasse erlaubt die PPL den gemeinsamen Zugriff auf eine Variable, ohne dass Data Races entstehen. Schließlich machte Bernd noch darauf aufmerksam, dass die Task-Parallelität das asynchrone Ausführen von Anwendungen erlaubt, indem Task-Gruppen definiert werden. Und ein wichtiger Tipp lautete abschließend: Fehlerfreie Parallelprogrammierung hat sehr viel mit lokalen Variablen zu tun, auf die man nicht von außen zugreifen darf.

Anschließend gab Volker Jungbluth sein Wissen ins Sachen Task Pattern Library (TPL) zum Besten. TPL entspricht in vielen Aspekten der PPL, ist allerdings für die Parallelisierung von Managed Code entwicklelt worden. Ein wichtiger Bestandteil des .NET4-4-Frameworks ist übrigens PLINQ, mit dem man sich als Programmierer laut Volker unbedingt beschäftigen sollte. So sind beispielsweise mit der Methode AsParallel() parallele Abfragen auf Datenstrukturen recht einfach möglich. Interessant fand ich auch die Feststellung, dass Parallel_for-Konstrukte mit dem Partitioner deutlich schneller laufen als ohne.

Weitere Erkenntnisse der Jungbluth’schen Techsession:

• Mit parallel_invoke() lassen sich mehrere Aufgaben auf Threads verteilen, ohne dass man sich explizit darum kümmern muss

• Mit Futures lassen sich task-basierte Ergebnisse im Hintergrund berechnen

• Mit continuation() lassen sich Task-Ketten erstellen, die dank der Lambda-Funktionen Ergebnisse übergeben können.

Nach soviel Parallelprogrammierung unter .NET 4 kam Bernd nochmals auf OpenMP zu sprechen, dass sich zwar am Thread-Konzept orientiert, aber gerade für das Parallelisieren von einfachen Schleifenkonstrukten prima geeignet ist. Daher ist OpenMP vor allem für mathematische Algorithmen eine gute Alternative zu TPL oder PPL, die in der Anwendung doch recht kompliziert sind.

Das Gute an OpenMP ist der Schalter /openmp, der beim Compileraufruf verwendet wird – oder auch nicht. Das erleichtert das Parallelisieren von seriellem Code erheblich, da beim Auftreten von Problemen der OpenMP-Schalter einfach nicht zum Einsatz kommt und die Anwendung zu Testzwecken seriell ausgeführt wird. Ach ja: Auf Basis des Intel-C++-Compilers lassen sich mit dem richtigen Switch fehlerhafte OpenMP-Konstrukte aufspüren.

Toll an OpenMP sind aber auch andere Aspekte:

• Für nicht-ausgewogene Schleifen verteilt OpenMP mit der Mehtode parallel_for_schedule() ganze Schleifenteile gleichmäßig auf auf jeden Thread. Das garantiert eine effiziente Ausführung von parallelen Schleifen.

• Mithilfe der OpenMP-API open_set_num_threads(int) wird die Anzahl der vorhandenen Thread-Ressourcen bestimmt und somit optimal genutzt.

• OpenMP-Variablen sind standardmäßig “shared”. Private-Variablen müssen daher explizit deklariert werden.

• Was für die TPL/PPL der Invoke-Befehl ist, heißt bei OpenMP “sections”.

• Mit dem OpenMP-Pragma omp parallel for if(Anweisung) lassen sich bedingte OpenMP-Schleifen bauen.

Review: Multicore-Programmierung auf den dotnetpro.powerdays, Teil1

Kaum sind die dotnetpro.powerdays vorbei, sitze ich schon wieder im Zug, auf dem Weg nach Frankfurt am Main, um mich auf dem dort stattfindenden Samsung Developer Day ein wenig über das samsung-eigene Mobil-OS Bada zu informieren. Die Zeit hier im ICE will ich mir mit dem ersten Teil meiner persönlichen Multicore-Event-Rückschau vertreiben.

Der Multicore-Programmierungs-Track auf den dotnetpro.powerdays 2010 wurde von Mario Deilmann eröffnet, der sich bei Intel u.a. um das Thema Compiler kümmert. Aber nicht nur das: Mario weiß auch eine Menge zu erzählen über die passenden Multithreading-Konzepte, was er auf der Entwicklertageskonferenz auch tat.

Seine Keynote fing mit einem grundsätzlichen Statement an: Die Multicore-Programmierung unterscheidet sich unter anderem in Sachen Abstraktionsebenen Das beginnt bei den eher komplizierten Thread-APIs, geht über OpenMP und Intel TBB und endet bei Tasks und den zugehörigen parallel-tauglichen Architekturen. Dabei gilt festzuhalten, dass je nach Abstraktionsgrad das Parallelisieren mithilfe der jeweiligen Methode mal mehr oder mal weniger kompliziert ist. So stellt sich das Parallelisieren mithilfe von POSIX-Threads kompliziert und fehleranfällig dar und skaliert darüber hinaus sehr schlecht.

Daneben sind Konzepte wie OpenMP ein guter Schritt in die richtige Richtung, allerdings basiert OpenMP immer noch auf expliziten Threads, was möglichst unter allen Umständen vermieden werden sollte. Jedoch konnten die Anwesenden später von Bernd Marquardt lernen, dass OpenMP vor allem für mathematische Anwendung oftmals eine gute, weil einfach anzuwendende Alternative ist.

Die beste Methode ist in vielen Fällen allerdings das Abstrahieren von Threads auf Basis von Tasks. Dies erfordert aber den Einsatz des passenden Frameworks inklusive der entsprechenden Entwicklungsumgebung. Solch ein Framework ist .NET 4 samt Visual Studio 2010, das ja noch recht jung ist. So hilft .NET 4 mithilfe von speziellen Funktionen, Klassen und Methoden, Anwendungen zu parallelisieren, ohne dass der Entwickler sich um das Erstellen, Verwalten und Anhalten/Löschen von Threads kümmern muss. Zudem helfen Thread-Pools beim optimalen Verteilen der Tasks auf die erforderlichen Threads. Dabei kommen Techniken wie Thread Stealing zum Einsatz, was ein effizientes Ausnutzen der vorhandenen Ressourcen garantiert.

Ein weiteres in Frage kommendes Parallel-Konzept befindet sich derzeit im Beta-Status und nennt sich Cilk, es ist einem Projekt des MIT entsprungen. Cilk wird Teil der nächsten C++-Compiler-Version von Intel sein. Mit Cilk bekommen Programmierer und Software-Entwickler ein mächtiges Tool zum nahezu automatisierten Parallelisieren von Anwendungen an die Hand. Cilk lässt sich laut Mario an einem Nachmittag erlernen und erfordert keine Änderungen am vorliegenden Quellcode. Allerdings sollte man sich vor dem Parallelisieren ein paar Gedanken darüber machen, wie der vorhandene Code möglichst effizient strukturiert werden kann, so dass Cilk seinen Job optimal erledigt.

Natürlich bietet Cilk Konstrukte wie parallel_for-Loops und beherrscht auch das Worker Stealing. Daneben reduzieren Hyperobjects die Gefahr von Data Races, ohne dass der Quellcode per Locks “serialisiert” werden muss. Sehr cool ist auch der Einsatz eigener Reducer, die deutlich flexibler als unter OpenMP und Intel TBB arbeiten Zudem generiert das Erstellen von Tasks mithilfe von Cilk deutlich weniger Overhead als das Erstellen von Threads bei vergleichbaren Konzepten wie OpenMP.

So, und wen Cilk jetzt so richtig neugierig gemacht hat, sollte dieses Blog in den nächsten Tagen immer wieder besuchen. Denn ich werde kommenden Dienstag mit Mario zusammensitzen und alles über Cilk aus ihm herausquetschen. Und die nächsten Teile meiner Multicore-Miniserie anlässlich der dotnetpro.powerdays gibt es natürlich auch sehr bald. See you then!