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!

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

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

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

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

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

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

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

Den Anfang macht 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.

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

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

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

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

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

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

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

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

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

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.

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!

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.

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.

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!

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

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

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

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

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

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

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

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

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.

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.

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!

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.

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.

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.

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!

• Parallel-Programmierung – wie geht’s und das bringt’s
• Parallelisierung von nativem Code
• Parallelisierung mit Managed Code
• Parallelisierung im OLTP-Alltag
• Parallelisierung von Berechnungen mit OpenMP
• Abschlussdiskussion | CUDA – Die etwas andere Art schnell zu rechnen

Also, ich freu’ mich drauf! Dann bis morgen…

Einer der großen Meilensteine war dabei die Übernahme des Embedded-Softwareherstellers Wind River durch Intel.

Absolut richtig. Allerdings ist die Schlussfolgerung des Kollegen Kroll nicht ganz zutreffend:

Einzig und allein die Ankurbelung des Prozessorgeschäfts ist die Triebkraft, die die  Aktivitäten Intels antreibt.

Das stimmt im Falle des Wind-River-Deals so nicht ganz, wenn man sich die derzeitige Embedded-Strategie Intels ansieht. Denn mit der Akquisition des Embedded-Spezialisten hat man nicht nur in Sachen Multicore und Parallelisierung viel Expertise eingekauft, sondern auch eine Menge Know-how im Bereich Mobile Linux und Mobile Gadgets ins Haus geholt. Und das kann Intel hinsichtlich seiner Moorestown-MeeGo-Smartphone-Aktivitäten ganz gut gebrauchen.

Vielmehr wird Intel auch mit der Software »inside« bleiben und Entwicklungswerkzeuge, Bibliotheken und Middleware für Betriebssystemhersteller und Anwendungsentwickler anbieten.

Diesen Passus finde ich ein wenig verwirrend. Klingt so, als ob Intel gerade dabei ist, zur Beschleunigung bestehender Software-Titel Tools auf den Markt zu bringen, die Software-Entwickler dabei unterstützen sollen, ihre Apps zu parallelisieren. Dass das so nicht stimmt, weiß der Autor allerdings schon, nur an dieser Stelle könnte der Eindruck entstehen, als ob Intel mit Software-Tools bis dato nix am Hut hat.

Echte Parallelität und »paralleles Denken« bei der Konzeption von Anwendungen stehen hingegen noch ganz am Anfang.

Hm, wie soll man diese Aussage bewerten? Sicher, viele Entwickler verlassen sich nach wie vor darauf, dass ihre Anwendungen von schneller werdenen Prozessoren und Architekturen beschleunigt werden, was natürlich nicht stimmt. Allerdings sind vor allem die größeren Entwicklerschmieden schon längst auf den Parallel-Zug aufgesprungen. Da kann man einfach mal bei DivX, Nik Software, Crysis, Exasol, Maxon, Nero und all den anderen nachfragen.

Eine fest codierte Verteilung (z.B. mit pthreads oder Windows threads) ist aber wenig zukunftssicher.

Absolut richtig! Der daraus resultierende Rat, den Software-Spezialisten wie Mario Deilmann oder andere geben, lautet: “Denkt in Tasks, nicht in Threads!”. Denn das thread-basierte Programmieren läuft bei vielen Anwendungen auf eine schlecht skalierende Programmausführung hinaus und ist zudem sehr fehleranfällig. Viel besser und effizienter ist es hingegen, seine Anwendung von Anfang an so zu strukturieren, dass eine Abstraktion des Quellcodes möglich ist. Und mit den richtigen Frameworks wie Intel TBB oder .NET 4 von Microsoft muss sich der Programmierer um das Verteilen der Tasks auf die zugehörigen Threads gar nicht mehr kümmern.

Allerdings ist eine neue Programmiersprache für die Parallelverarbeitung nicht in Sicht [...]

Tja, eine gewagte Aussage. Denn mit funktionalen Programmiersprachen wie F#, die mit dem Erscheinen von Visual Studio 2010 Bestandteil der Microsoft-Entwicklungsumgebung ist, lässt sich die Parallelprogrammierung durchaus vereinfachen. Inwieweit sich F# und andere funktionale Sprachen durchsetzen werden, ist natürlich fraglich.

Viele Entwickler suchen allerdings nach weniger anspruchsvollen Erweiterungen [wie OpenMP und die MPI-Bibliothek], mit denen sich in C/C++ geschriebene Desktop- und Embedded-Anwendungen parallelisieren lassen [wie mit Intel TBB].

Es stimmt natürlich, dass OpenMP nicht so mächtig ist wie die C++-Bibliothek Intel TBB. Aber OpenMP als anspruchsvolle Erweiterung zu bezeichnen, ist ein bisschen übertrieben. Gerade mit OpenMP lassen sich mit wenigen Handgriffen vor allem Schleifen parallelisieren. Hierzu bedient man sich lediglich einiger, weniger Pragmas, die in den bestehenden Quellcode eingefügt werden müssen. Der Rest geschieht dann quasi von selbst.

Sein aktueller Artikel beschäftigt sich im Grunde mit zwei Themen: Mobile und Multicore. Denn zum einen geht es um Atom-Prozessoren und zum anderen um das Parallelisieren von Netbook-Apps. Streng genommen funktioniert das Multithreaden von mobilen Anwendungen ganz ähnlich wie auf Notebook- oder Desktop-Plattformen. Allerdings widmet Edmund seinen Beitrag nicht der Entwicklung von Windows-Software, sondern der von linux-basierten Anwendungen.

Hierzu bietet Intel nämlich zwei spezielle Entwicklungssuiten, die sich beide im Linux-Umfeld einsetzen lassen. Die Tools nennen sich Intel Application Software Development Tool Suite und Embedded Software Development Tool Suite. Die Tools-Sammlungen unterscheiden sich vor allem im Debugger, nämlich dem JTag-Debugger.

Mithilfe von Edmunds Artikel lernt man die Hauptbestandteile der Entwicklersuites kennen. Das ist vor allem…

… der Intel C++-Compiler, der an die Besonderheiten der Atom-Prozessoren angepasst wurde,

… die IPP-Bibliothek, die mehr als 10.000 thread-sichere Funktionen für Multimedia-Apps umfasst,

… der VTune Performance Analyzer zum Aufspüren von Programmengpässen, also Hotspots,

… der Intel JTag-Debbuger, mit dem sich host-basiert Fehler aufspüren und eliminieren lassen,

… der Applikationsdebugger, der eine Ergänzung zum JTag-Debugger darstellt.

Klar, dass sich sämtliche Tools innerhalb der linux-typischen Eclipse-Umgebung einsetzen lassen. Das gewährt das gewohnte Entwickeln und Testen von mobilen Linux-Programmen für MeeGo und andere Derivate.

Das Geld scheint wohl ziemlich gut angelegt zu sein, denn es werden wieder rund 370 Techsessions und  mehr als 150 so genannte Hand-on-Workshops angeboten, also mehr als 100 Sessions pro Tag. Da sollte schon das eine oder andere dabei sein, was für euch relevant und interessant ist. Aber natürlich ist solch eine Konferenz auch zum Netzwerken gut und zum Kennenlernen und zum Feiern am Abend.

Und falls ihr wissen wollt, mit welchen Themen wir uns hier auf dem Software Dev Blog während der letztjährigen Tech-Ed Europe beschäftigt haben: ein Mausklick genügt.

Tipp 1: Mithilfe bestimmter Compiler-Einstellungen lassen sich mit ganz wenig Aufwand Programme nahezu doppelt so schnell ausführen. So sorgt beispielsweise der Switch /Qopenmp dafür, dass vorher eingefügte OpenMP-Pragmas vor allem Schleifen parallelisieren. Ok, hierzu ist naürlich schon ein wenig Handarbeit notwendig. Aber es lohnt sich!

Tipp 2: Die registernahe Parallelprogrammierung mithilfe von SSE-Operationen bietet ebenfalls eine ganze Menge an Beschleunigungspotenzial. So lassen sich mit wenigen zusätzlichen Programmcodezeilen beispielsweise Bildverarbeitungsalgorithmen erheblich beschleunigen. Also ohne größeren Aufwand.

Tipp 3: Beim Einsatz entsprechender Optimierungstools wie Intel VTune Analyzer sollte man tunlichst darauf achten, die zu parallelisierende Software nicht vollständig analysieren zu wollen, da VTune beispielsweise einige tausend Events erstellt. Dabei geht es doch meist nur um wenige Flaschenhälse, deren Beseitigung die Anwendung spürbar beschleunigt. Das sind beispielsweise nicht vollständig ausgeführte Funktionen, mangelhafter Datenaustausch zwischen CPU und Speicher, ungewollte Leerläufe und Cache Misses.

Tipp 4: Beim Parallelisieren sollte man auf die wirklich kritischen Bereiche der Anwendung achten. Das sind vor allem die rechenintensiven, zeitraubenden Funktionen und Module, auf die es gilt sich beim Parallelisieren zu konzentrieren. Tools wie der Parallel Amplifier können dabei helfen, genau diese Programmbereiche aufzustöbern. Dabei ist natürlich auch ein wenig Kenntnis bezüglich der verwendeten Algorithmen und ihres Ressourcen-Hungers hilfreich.

Tipp 5: Oberste Priorität sollte sein, dass die parallelisierte Anwendung keine Laufzeitfehler produziert (Stichworte: Race Conditions, Dead Locks, etc.). Auch hierfür empfiehlt sich der Einsatz geeigneter Software-Tools wie des Intel Parallel Inspector, der mögliche Verklemmungen aufspürt, indem das Programm ausgeführt wird und sich so die eventuellen Ergebnisse ermitteln lassen, die zu Laufzeitfehlern führen können.

So, und was gibt es abschließend noch zu Olivers und Bernds Vorträgen zu sagen? Nun, beide waren (a) sehr unterhaltsam und (b) sehr informativ. Aber gut, das war ja auch nicht anders zu erwarten.

Oliver Sturm ist bestimmt vielen von euch ein Begriff: er ist unter anderem C#-MVP, betreibt ein eigenes Blog und twittert sogar ab und an. Seine Session trug den Titel “Parallelisierung mit funktionalen Ansätzen in C#”. Dabei ging es – grob gesagt – um den Multicore-Shift (“Wie übersetzt man das eigentlich?!”), um das Parallelisieren von Quellcode mithilfe der Parallel Extensions in .NET und um entsprechende funktionale Ansätze, demonstriert anhand zweier Beispiele (das Filtern von Namenslisten und die parallelisierte Erzeugung von Mandelbrotbäumen). Interessant fand ich übrigens Olivers Versuch, die Begriffe “Multithreading”, “Concurrency” und “Parallelism” voneinander abzugrenzen, da diese im englischen Sprachraum äußerst oft synonym verwendet werden. Tja, und den Rest seiner Präse schaut ihr euch am besten selbst an.

Bernd Marquardt beschäftigte sich dann mit einem ganz ähnlichen Thema, wenngleich aus einer anderen Richtung kommend: “Parallelprogrammierung mit der TPL”. TPL steht für Task Parallel Library, mit deren Hilfe das Parallelisieren von Managed Code vereinfacht werden soll. Natürlich zeigte auch Bernd zunächst einmal, dass die Prozessoren nicht mehr schneller werden, sondern “nur” noch mehr. Und dass Software-Entwickler aus diesem Grund eine ganze Menge Hirnschmalz auf die Optimierung ihrer Anwendungen verwenden müssen, damit diese auch optimal skalieren (die Anwendungen, nicht die Entwickler!).

Bernd stellte einstiegsweise die verschiedenen Parallelisierungsmodelle vor, über die Mario ja schon gut zwei Stunden vorher geredet hatte. Das erste praktische Beispiel war die parallele Erweiterung von LINQ, also PLINQ, die Microsoft seinem .NET-4-Framework spendiert hat. Damit lassen sich parallel ausführbare Datenbankabfragen generieren, die automatisch auf die vorhandenen Prozessorkerne und Threads verteilt werden. Aber auch das Parallelisieren von Schleifenkonstrukten mit neuen Funktionen wie Parallel.For() und Parallel.ForEach() waren Bernd ausführliche Erläuterungen wert.

Und so ging es dann lustig weiter: Codeblöcke parallelisieren mit Parallel.Invoke(), Task-Klassen einsetzen (vergleichbar mit der Threadpool-Klasse), Concurent Exceptions verwenden, Synchronisierungsprobleme erkennen und einiges mehr. Und wer das alles genauer wissen will, sollte sich einfach die Folien von Bernds Session auf seinen Rechner laden.

Neben dem Schwierigkeitsgrad unterscheiden sich die zwei Sub-Wettbewerbe im Schreibaufwand, der mit der Einreichung der jeweiligen Lösung einher geht. So müssen die Multicore-Erfahrenen neben dem parallelisierten Quellcode auch eine genaue Beschreibung einreichen, die etwas darüber verrät, wie das Problem angegangen und gelöst wurde. Das bleibt den Newbies erspart. Die haben vermutlich auch genug damit zu tun, sich erst mal in das Thema Parallelprogrammierung einzuarbeiten.

Der Ablauf der Intel Thread Challenge 2010 sieht wie folgt aus:

• Phase I umfasst zwei Probleme, die jeweils innerhalb von vier Wochen gelöst werden müssen. Die erste Aufgabe ist bereits online und muss bis zum 27. Juni gelöst und eingereicht werden (je nach Schwierigkeitsgrad mit oder ohne Schriftsatz). Ab dem 28. Juni gibt es die zweite zu lösende Aufgabe, für die wieder vier Wochen zur Verfügung stehen. Die jeweils ersten drei besten Lösungen erhalten Visa-Geschenkkarten im Wert von 50, 35 und 25 Dollar bei den Einsteigern und 50, 100 und 15o Dollar bei den Fortgeschrittenen.

• Phase II beginnt nach diesen vier Wochen, also am 26. Juli. Während dieses zweiten Abschnitts müssen dann sogar vier Aufgaben gelöst werden, die wiederum alle vier Wochen online gehen. Am Schluss werden alle Punkte der eingereichten und besten Lösungen der Phase II zusammengezählt, und der Sieger erhält einen Super-Duper-Spezialpreis. Im Falle des Einsteiger-Wettbewerbs ist das ein schicker Apple iPod touch und der beste Programmierer in der Kategorie “Fortgeschrittene” darf sich über ein brandneues Notebook freuen.

So, alle also, die an der Thread Challenge 2010 mitmachen wollen, sollten sich die Spielregeln und Preise noch mal genauer ansehen. Und wer auf der Suche nach dem einen oder anderen unterstützenden Tool ist, wird bei Intel auch fündig. Viel Spaß!

Dr. Mario Deilmann (so sein vollständiger Name) ist bei Intel für Compiler und ähnlich geartete Software-Tools zuständig. Mit seiner Lunch-Session ging er der Frage nach, welches Programmier- bzw. Thread-Modell für skalierende Anwendungen das beste sei. Skalierend bedeutet in diesem Zusammenhang, dass parallelisierter Quellcode nicht nur optimal auf zwei Prozessorkerne verteilt wird, sondern auch auf vier, sechs, acht oder 256 Kernen läuft – und zwar ohne Leistungseinbußen.

Hierfür ist laut Mario zunächst einmal ein passendes Profiling-Tool wie der Intel VTune Performance Analyzer erforderlich, mit dem man diejenigen Funktionen, Module und andere Stellen des Quellcodes aufspürt, die für die meiste Rechenleistung und -zeit verantwortlich sind. Denn das sind oft die Stellen, an denen man als Software-Entwickler ansetzen sollte. In vielen Fällen sind das zum Beispiel Schleifenkonstrukte, die sich bestens zum Parallelisieren eignen.

Eine der passenden Programmiermodelle wusste Mario natürlich gleich darzustellen: OpenMP. Allerdings weist diese pragma-basierte Parallelisierung von seriellen Anwendungen auch diverse Nachteile auf: Man denkt als Programmierer in Threads anstatt in Tasks (was laut Mario eigentlich ein absolutes No-Go sein sollte), es lassen sich keine eingebetteten Parallelkonstrukte realisieren und mit lokalen Daten geht OpenMP ebenfalls nur suboptimal um. Aber für die schnellen ersten Ergebnisse für parallel ausführbare Programme ist OpenMP laut Mario eine gute Wahl.

Außerdem unterstützt OpenMP keine objektorientierten Programmiersprachen wie C++, was natürlich in vielen Fällen ein klares KO-Kriterium ist. Aber wozu gibt es beispielsweise die Intel Threading Building Blocks. Mit dieser Thread-sicheren, hochoptimierten Sammlung von fertigen C++-Konstrukten lassen sich sequentiell programmierte Anwendungen recht schnell und ohne größere Kenntnisse der Parallelprogrammierung in parallel ablaufende Programme umwandeln. Praktisch an Intel TBB ist deren Vielseitigkeit: OS-seitig werden Linux, Mac OS und Windows unterstützt, und es gibt sogar eine nicht-kommerzielle Variante, die den LGPL-Lizenzrichtlinien unterliegt.

Neben OpenMP und Intel TBB existieren noch weitere Ansätze, wie sich Software parallelisieren lässt. Dazu gehört das noch recht junge Projekt Cilk++ von Intel, das einen ähnlichen Weg einschlägt wie Intel TBB, allerdings einen Parallel Debugger sein Eigen nennt, ein SDK bietet und auf hunderten von Prozessorkernen skalieren soll. Und vergessen sollte man natürlich auch nicht Parallel Studio, das unter anderem die Tools Parallel Inspector und Parallel Amplifier aufweist, mit deren Hilfe man Fehler im Quellcode aufspüren kann (Inspector) und sich die Anwendung weiter optimieren lässt (Amplifier). Das geht sogar so weit, dass Laufzeitfehler wie Race Conditions und Dead Locks aufgespürt werden können – bevor dies der Anwender später tut.

So, und die Sessions von Oliver Sturm und Bernd Marquardt sind dann morgen dran. Versprochen!

Da es auf diesem Blog ja um das Thema Multicore-Programmierung geht, widmet sich dieser Blogbeitrag der dotnet Cologne 2010. Zunächst einmal möchte ich den Organisatoren rund um Albert Weinert, Roland Weigelt und all den anderen ein großes Kompliment aussprechen: Ihr habt da wirklich ein tolles Event mit tollen Themen, Sessions und Sprechern organisiert. Ok, dass der Kaffee nicht immer warm war und die Technik gleich mal am Anfang nicht so recht wollte, übersehe ich gerne. Wichtig ist doch, dass die Inhalte stimmen und gut rübergebracht werden. Und das war auf jeden Fall so. Also zumindest kann ich das von den Vorträgen behaupten, die ich besucht habe.

Meine persönliche Sessionplanung umfasste vier Vortragende: Rami Radi und Mario Deilmann von Intel, den sehr unterhaltsamen Oliver Sturm und zu guter Letzt den werten Bernd Marquardt, der auf solch einer Veranstaltung natürlich nicht fehlen darf (und den ich im Juni auf den dotnetpro powerdays wieder erleben werde).

Ramis Session war wie immer sehr technisch orientiert und fand wegen der vielen Codebeispiele das Interesse der Zuhörenden, die sich im Raum “Bremen” eingefunden hatten. Und die wurden auch nicht enttäuscht: Rami legte sehr unterhaltsam dar, wie das Dreigestirn Windows 7, .NET 4 und Multicore-Architekturen voneinander profitieren. Dabei ging es unter anderem um ein wenig Grundlagenwissen in Sachen Nehahlem, also Turbo Boost, Quickpath-Architektur und andere Dinge.

Aber auch über die Verbesserungen von .NET 4 aus Multicore-Sicht wusste Rami anschaulich zu berichten: So stellte er Features wie Thread Scheduling, Thread Pooling, Garbabe Collection, TPL sowie PLINQ vor. Dabei gewährte er interessante Einblicke und verriet wichtige Details wie die parallele Aktualisierung von Gen-0- und Gen-2-Daten, die bei der Garbage Collection anfallen. Zudem ging er näher auf das Work-Stealing des in .NET 4 komplett überarbeitenden Thread Managers ein, bei der sich unterbeschäftigte Thread-Queues einfach Threads anderer Queues “klauen” können und so die Effizienz des Threadpool-Managers steigern.

Sehr erstaunlich fand ich auch die Tatsache, dass unter .NET 4 nun nicht mehr 25 Threads pro CPU verwaltet werden können, sondern derer 250! Hierfür ist allerdings ein sehr guter Scheduler notwendig, was Microsoft mit dem neuen .NET-Framework wohl gelungen ist.

Nach so viel Theorie wurde es dann sehr praktisch: Rami zeigte all die Verbesserungen unter .NET 4 im Hinblick auf seine Multicore-Fähigkeiten anhand eines Maze-Solvers, bei dem es um den den schnellsten Weg innerhalb eines Labyrinths von A nach B geht. Hierzu bediente er sich eines kleinen .NET-Programms, das er einmal unter .NET 3.5 und .NET 4 laufen ließ. Alleine schon der Umstieg von der älteren auf das brandneue Framework brachte beim Zeichnen des Labyrinths und dem anschließenden Finden des optimalen Wegs Zeitverbesserungen. Ganz zu Schweigen vom Unterschied zwischen dem seriell programmierten Programm und der Multicore-Variante mit mehreren Threads.

Abschließend startete Rami noch ein wenig den VTune Performance Analyzer, um der anwesenden Zuhörerschaft zu demonstrieren, wie sich mit dem Intel-Tool in .NET-Anwendungen solch hässliche Dinge wie Bottlenecks und False-Sharing-Probleme aufspüren lassen. Und wenn die Zeit nicht auf einmal vorbei gewesen wäre, hätte Rami wohl weitere zwei Stunden damit zugebracht, VTune in all seinen Facetten und mit all seinen Möglichkeiten vorzuführen.

Und was Mario, Oliver und Bernd in petto hatten, erfahrt ihr im zweiten Teil meiner dotnet-Cologne-2010-Berichterstattung.

In Köln bin ich, weil Intel dort einen Teil des Sponsorings übernommen hat und ich live aus dem Holiday Inn berichten werde, in dem die dotnet Cologne 2010 stattfindet. Das Programm habe ich ja schon in großen Teilen vorgestellt. Allerdings haben sich seitdem zwei Änderungen ergeben, die vor allem Intel betreffen. Und die will ich euch natürlich nicht vorenthalten.

Zum einen wird Mario Deilmann nicht über Intel Parallel Studio mit .NET und Visual Studio sprechen, sondern im Rahmen einer Lunch-Session die bekanntesten Windows-Modelle der Parallelprogrammierung vorstellen. Dabei geht es sicherlich um Multithreading-Konzepte wie OpenMP, APIs und Intel TBB. Und sicherlich wird auch Parallel Studio seinen Platz finden, alleine schon wegen der Unterstützung seitens Visual Studio 2010.

Zum anderen wird Kollege Rami Radi von Intel eine Stunde lang über Windows 7, .NET 4 und die Multicore-Programmierung sprechen. Wer sich hier schon länger tummelt, wird sich möglichweise daran erinnern, dass Rami diesen Vortrag schon mal gehalten hat. Womit er allerdings nicht minder aktuell wäre, denn das Thema Parallelprogrammierung hat mit Visual Studio 2010 und .NET 4 ja schließlich gerade erst begonnen.

Für alle, die der dotnet Cologne 2010 leider nicht beiwohnen können, folgt hier die gute Nachricht: Ich werde für euch von dort einen ganzen Tag lang über die wichtigsten und interessantesten Sessions in Sachen Parallelprogrammierung berichten. Macht euch schon mal einen dicken, roten Kringel um den 28. Mai 2010!

Wir, das sind wie schon so oft ich selbst und Tom, der Videokamera, Stativ, Licht und anderes Zubehör dabei hat, um mit mir informative Interviews zu drehen, vor Ort zu schneiden, zu verbloggen und gleichzeitig auf Youtube & Co. zu stellen. Das wird wieder drei Tage lang Fun und richtig Arbeit. Wir freuen uns schon drauf!

Als kleines Aufwärmprogramm hab ich mir mal die Intel-Sessions der GDC 2010 angesehen, die vom 9. bis 13. März 2010 im kalifornischen San Francisco stattgefunden hat. Das könnte  diverse Hinweise darauf liefern, was uns in Köln drei Tage lang so alles erwartet.

• Chuck Desylva und Jeff Laflam warfen gemeinsam einen Blick auf die aktuelle Generation der integrierten Grafikchips, die Intel mit Einführung der Arrandale-Prozessoren (z.B. Core i5) vorgestellt hat. Aus Entwicklersicht sind Features wie DirectX-10- und OpenGL-2.1-Support interessant, aber auch die Dekodierung von HD-Videostreams (MPEG-2, VC-2, AVC) und der Einsatz von Clear Video HD-Technik. Daneben sind auch die Leistungszuwächse bemerkenswert, die sich beim Datendurchsatz in Sachen Vertex Shading, Rasterisierung, Texture Mapping und Pixel Shading ergeben. Die Session konzentrierte sich vor allem auf die Spieleoptimierung mithilfe bestimmter Tools wie VTune Performance Analyzer und Intel Graphics Performance Analyzer.

• Ron Fosner ging da schon einen ganzen Schritt weiter: Wie kann es gelingen, aus einem sequentiell programmierten Spiele-Titel ein Multithreading-Konstrukt zu bauen, das auf jedem Multicore-Rechner der Welt optimal skaliert? Es geht dabei um Threads versus Tasks, um Thread Pools, um Task Priorities, wie man mit Code- und Daten-Abhängigkeiten umgeht und vieles mehr. Das Ganze wurde natürlich anhand von echten Code-Beispielen demonstriert.
• Stan Melax, Quentin Froemke und Ganesh Rao begaben sich gemeinsam auf eine Zeitreise. Sie sprachen nämlich über eine Ära, in der das SIMD-Computing von Intel eingeführt wurde und die bis heute Bestand hat (und mit der kommenden Intel-Compiler-Version 12 in Form der AVX-Register und -Operationen die Evolution fortsetzt). Dabei geht es um die parallele Registerverarbeitung und darum, welche Leistungssteigerungen dadurch möglich sind. Denn der optimale Einsatz von SIMD-Befehlen erfordert kaum Anpassungen am vorhandenen Quellcode.

• Orion Granatir war gleich dreimal fleißig während der GDC 2010. Sein persönliches Highlight war sicherlich der Ein-Tages-Workshop, in dem es unter seiner Anleitung darum ging, ein sequentiell programmiertes Spiel so anzupassen und zu parallelisieren, dass es optimal auf einem Multicore-Rechner mit integrierter Grafik läuft. Dazu passte auch seine Session mit dem vielversprechenden Titel “Fürchte dich nicht vor Threads”. Hier wurden vier verschiedene Ansätze betrachtet, wie sich Spieletitel parallelisieren lassen. Und seine dritte Präsentation widmete sich einem ganz anderen Thema, das aber mindestens genauso wichtig scheint: Wie optimiere ich meine Spieletitel für Netbooks?

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.

Wie ich überhaupt darauf komme? Nun, ein Microsoft-Mann hat mich in die Tech-Ed-Facebook-Gruppe eingeladen, und da konnte ich natürlich nicht widerstehen, mich derselben anzuschließen. Man erfährt noch nicht wirklich viel, aber zumindest ist dort nachzulesen, dass alle Frühanmelder stolze 500 Euro sparen können, wenn sie sich bis zum 5. Juli anmelden (dann kostet das Ticket 1.395 Euro).

Zwar ist die Tech-Ed-Seite noch nicht umgestellt (es geht noch um 2009!), und damit auch die Anmeldung noch nicht möglich, aber beide Missstände sollen wohl demnächst behoben sein.

Falls ihr den Termin im Kalender schon mal eintragen wollt: die Tech-Ed Europe 2010 findet vom 8. bis 12. November statt, und zwar wieder in Berlin auf dem altehrwürdigen IFA-Messegelände, was letztes Jahr ganz gut geklappt hat. So, und der Vollständigkeit halber will ich den Twitter-Alias nicht verschweigen, mit dem ihr der Tech-Ed Europe 2010 folgen könnt: teched_europe. Und falls ihr euch das bis November merken könnt: Der Hashtag steht auch schon fest und lautet #tee10.

Ach ja: Ich war letztes Jahr live in Berlin dabei und habe mit Tom zusammen ein paar schöne Blogbeiträge samt Videos erstellt und veröffentlicht. Dabei haben wir unter anderem darüber berichtet, wie…

… .NET-Entwickler mithilfe von VTune Performance Analyzer Bottlenecks aufspüren können

… die CCR .NET-Entwicklern bei der Parallelprogrammierung hilft

… .NET-Entwickler vom Multithreading profitieren

… Visual Studio und .NET 4 Parallelprogrammierer unterstützen

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

Optionaler C++0x-Support

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

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

Kompatibel mit Microsoft Visual Studio 2010

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

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

Verbessertes Debuggen

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

Scheduler-Support (task::enqueue)

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

Leistungsverbesserungen

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

und einiges mehr.

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

The Java platform is designed from the ground up to support concurrent programming, with basic concurrency support in the Java programming language and the Java class libraries. Since version 5.0, the Java platform has also included high-level concurrency APIs.

Verwirrend daran ist die Tatsache, dass davon die Rede ist, Java sei von Hause aus für die Parallelprogrammierung konzipiert worden. Das stimmt natürlich nicht, was im zweiten Satz auch klargestellt wird. Und der Hinweis auf die grundlegende Unterstützung in Sachen Multithreading in Java macht es ebenfalls deutlich: Java bietet zwar Multicore-Support, der ist aber nicht trivial anzuwenden und erfordert sicherlich mehr Informationen als die Lektion “Concurrency”, die auf der Sun-Seite zur Verfügung gestellt wird.

Nichtsdestotrotz ist dieser kleine Workshop ein guter Einstieg in die Welt der Java-Multicore-Programmierung. Es wird anhand kurzer Codebeispiele gezeigt, wie sich …

• Threads erzeugen und starten lassen
• Threads per Sleep Messages() temporär anhalten lassen
• Threads unterbrechen lassen
• Threads anhalten lassen, damit sie auf einen anderen Thread warten.

Ein etwas ausführlicheres Beispiel zeigt dann, wie aus diesen Anweisungen ein sinnvolles Konstrukt entsteht und welche Abhängigkeiten daraus resultieren.

Doch es ist in dem Mini-Workshop natürlich auch vom heiklen Thema Synchronisierung die Rede: Warum es wichtig ist, welche Methoden es gibt und wie sich Daten explizit synchronisieren beziehungsweise für andere sperren lassen.

Daneben finden sich in dem Workshop weitere Aspekte der Parallelprogrammierung in Java wie Dead Locks, Guarded Blocks und das Multithreading auf  höherer Ebene. Dabei wird gezeigt, wie man mithilfe von APIs von der reinen Thread-Ebene auf eine abstraktere Ebene kommt, um dort zu multithreaden.

Und es gibt sogar diverse Buchtipps, die sich mit dem Thema Parallelprogrammierung unter Java beschäftigen. Aber es existieren auch deutsche Fachbücher zu diesem Thema. So hat beispielsweise Rainer Oechsle “Parallele und verteilte Anwendungen in Java” verfasst (Hanser, ISBN-10: 3446407146, ca. 35 Euro). Dietrich Boles hat sich ebenfalls damit befasst und herausgekommen ist “Parallele Programmierung spielend gelernt mit dem Java-Hamster-Modell: Programmierung mit Java-Threads” (Vieweg+Teubner, ISBN-10: 383510229X, ca. 36 Euro).

• Zunächst einmal unterscheidet Microsoft in Sachen VS-2010-Download zwischen registrierten und nicht-registrierten Entwicklern. Alle, die also ein MSDN-Abo ihr eigen nennen, können sich Visual Studio 2010 und .NET 4 downloaden.

• Auch nicht-registrierte Anwender kommen in den Genuss von VS 2010, allerdings nur in der Testversion, die sich für 90 Tage auf dem Rechner installieren lässt. Dafür kostet die Trial-Variante natürlich nix. Test-Willige können dabei zwischen diversen Varianten wählen: Ultimate, Professional und Test Professional, und das entweder als ISO-Datei oder per Webinstaller. Außerdem braucht ihr noch die .NET-4-Laufzeitumgebung sowie diverse Tools, mit denen ihr eure Applikationen testen könnt. Dazu gehören die F#-Runtime, die Office-Runtime, der Team Foundation Server 2010 und der Team Explorer.

Ach ja, Kays Blogbeitrag hält noch weitere nützliche Infos bzw. Links zu Visual Studio 2010 parat: den Hinweis auf ein Einführungsvideo, die Empfehlung eines E-Books zum Thema VS-Migrierung, einen Workshop zum Erstellen von Cloud-Anwendungen mit VS 2010 und viele andere gute Tipps und Internet-Links. Also, ein Besuch des Giza-Blogs lohnt sich.

Ach ja: Für Visual Studio 2010 wird gerade die nächste Version der Multicore-Suite Parallel Studio entwickelt. Wer dabei als Betatester fungieren möchte, sollte mal hier vorbeischauen.

Einer der Hauptsponsoren auf dieser 2-in-1-Veranstaltung ist Wind River, ein Multicore-Spezialist und seit Mitte vergangenen Jahres zu Intel gehörend. Der Zusammenschluss von Intel und Wind River hat ja einen recht trivialen Hintergrund: Mit dem Embedded-Spezialisten Wind River sichert sich Intel einen riesigen Fundus an Multicore-, Linux- und Mobile-Gadgets-Wissen, das jetzt schon in diverse Tools und Lösungen einfließt, aber auch in künftige wie Smartphones und andere Gerätschaften, die Intel noch möglichst in diesem Jahr auf den Markt bringen will.

Aber zurück zum Multicore-Event: Dort gibt es ab heute bis Donnerstag Infos satt rund um die Themen Parallelprogrammierung, Multithreading und Co. Jeder Tag bietet drei Slots, die unterteilt sind in die Bereiche “Applying Multicore to Networking and Telecom”, “Resolving Multicore Debug Challenges”, “Parallelization and Application Partitioning”. Also geht es letztlich um das Verteilen, Testen und Implementieren von Multicore-Techniken.

Natürlich findet man auf der Multicore Expo 2010 alles, was man von solch einer Veranstaltung erwarten kann: ausführliche Workshops und TechTalks, Keynote Sessions, Sponsored Sessions und Paneldiskussionen. Dabei geht es um Themen wie “Simplifying Multicore”, “Software Development: the Key to Multicore Success” und “Community Creation for Embedded Multicore Processors & Applications”. Es stehen aber auch Dinge wie die mögliche Parallelprogrammierung für Atom-Prozessoren, Multicore und Cloud Computing und virtualisierte Multicore-Plafttformen auf der Agenda.

Und für alle, die nicht in San Jose dabei sein können, gibt es auf der Event-Seite im Anschluss an die Veranstaltung wieder sämtliche Präsentationen zum Download. Das hat voriges Jahr allerdings 150 Dollar gekostet, wenn man selbst nicht dabei war.

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

Nun, um an der Gestaltung der für Visual Studio 2010 optimierten Version von Parallel Studio teilzunehmen, könnt ihr euch für das zugehörige Beta-Programm registrieren. Allerdings handelt es sich dabei erst mal nur um eine Bewerbung. Ob man dann tatsächlich beim Beta-Test der nächsten Version von Parallel Studio dabei ist, entscheidet ein entsprechendes Gremium. Seid also sorgfältig beim Ausfüllen des Bewerbungsformulars, in dem Dinge abgfragt werden wie der Zeitraum des geplanten Umstiegs auf VS 2010, welche Programmiersprachen zum Einsatz kommen und ob die zu entwickelnden Anwendungen ausschließlich unter Windows laufen – oder auch nicht.

Doch was werden Software-Entwickler von der Kombination Parallel Studio/Visual Studio 2010 alles haben? Dazu gehören folgende Dinge:

• Eine äußerst leistungsstarke Speicher- und Thread-Analyse, die sowohl parallelen als auch sequenziellen Quellcode nach möglichen Flaschenhälsen und Fehlern untersucht.

• Der in Parallel Studio integrierte C++-Compiler ist vollständig kompatibel mit Microsoft Visual C++. Darüber hinaus ermöglicht der Intel-Compiler neue Vektormodelle und identifiziert sogar Bereiche innerhalb der Anwendung, die mithilfe einiger Handgriffe effizienter laufen, wenn man dort spezielle Vektoroperationen einbaut.

• Die Multithread-Bibliotheken der Intel Threading Building Blocks sind voll kompatibel zur Parallel Pattern Library, die einen wichtigen Teil des .NET-4-Frameworks ausmacht, wenn es um die Parallelisierung von Anwendungen geht.

• Aber auch die Intel Integrated Performance Primitives (IPP) sind bereits jetzt vollständig kompatibel mit Visual Studio 2010. Die IPP sind unter anderem wichtig bei der Programmierung von Multimedia-, Bildbearbeitungs- und Kommunikationstools.

Also, worauf wartet ihr noch? Als möglicher Beta-Tester seht ihr nicht nur als erster die nächste Version von Parallel Studio, sondern könnt sogar aktiv die Auswahl neuer Features mitbestimmen. Wenn das mal nix ist …

James Reinders in seiner Funktion als Chef-Entwickler bei Intel erzählte in seinen Vorträgen eine Menge über Parallel Studio und über geplante Projekte, die im Laufe der nächsten Monate realisiert werden. Aber auch Peter Norfolk von Bloor Research hatte das ein oder andere zu dem Thema zu sagen (mein Lieblingsspruch: “A fool with a tool is still a fool!”). Norfolk verwies in seiner Präsentation unter anderem auf den (bekannten) Effekt, dass bei der Anschaffung neuer (Multicore-)Systeme die vorhandene Software meist nicht skaliert und im Vergleich zur vorherigen Installation sogar schlechter laufen könnte. Und das macht natürlich niemandem Spaß.

Vor allem nicht im Business-Umfeld, auf das sich Norfolk bezog. Aber selbst wenn die Software an die neuen Multicore-Maschinen angepasst wurde (Stichwort: Multithreading), ergeben sich laut Norfolk möglicherweise auch Verstimmungen, wenn das Optimieren der Anwendungen nicht richtig geschehen ist (was beim Multithreaden durchaus vorkommt). Genauso wichtig wie das Parallelisieren von Business-Software ist laut Peter Norfolk aber auch das Parallelisieren der Geschäftsprozesse, damit sich diese auch auf die entsprechenden Algorithmen abbilden lassen. Das ist speziell im Business-Umfeld von entscheidender Bedeutung.

Eine weitere wichtige Erkenntnis der Intel Software-Konferenz 2010 lautet: Intel treibt die Software-Gemeinde weiter an und hilft ihr, Probleme besser und besser zu lösen. Das schafft der Prozessorhersteller einerseits mithilfe ständig verbesserter und neuer Tools, die beispielsweise bei der Parallelprogrammierung notwendig und hilfreich sind. Aber auch Projekte wie Intel Concurrent Collections oder Intel Cluster OpenMP zeigen stets neue Wege auf, wie Software-Entwickler ihre Produkte noch effizienter und eleganter in den Markt bringen können.

Eine weitere gute Nachricht: Intel bietet für die verschiedenen Stufen der Software-Entwicklung die passenden Tools, die sich Programmierer zu eigen machen können. Denn das eine, perfekte Werkzeug für sämtliche Aufgaben gibt es laut James Reinders nicht. Schade eigentlich …

Ach ja: Für die mobilen Entwickler hatte Uli Dumschat von Intel ebenfalls eine Menge nützlicher Infos und Tipps dabei. Aber das ist eine ganze andere Geschichte, die ich hier hoffentlich sehr bald veröffentlichen werde.

Wie sich das auf solchen Veranstaltungen gehört, gebührt das erste Wort dem Gastgeber, und das ist nun mal Ober-Parallel-Guru James Reinders, der gleich allen Anwesenden die Schuld für die Notwendigkeit der Parallelprogrammierung gab: “We are all guilty! We love data!” Und diese Sammelwut führt laut Reinders zwangsläufig dazu, dass sich die zu verarbeitende Datenmenge in den den nächsten Jahren exponentiell vervielfachen wird (Experten denken heute schon in Exabyte, also einer Trillion Byte). Und dieser Datenwust macht es unumgänglich, dass Daten möglichst parallel verarbeitet werden sollten. Hierfür benötigt man aber nicht nur schnelle Rechner und leistungsfähige Infrastrukturen, sondern auch hochoptimierte Anwendungen.

>> Den Rest des Originalbeitrags lesen …

Im zweiten Teil seines einleitenden Vortrags wurde James ein gutes Stück konkreter: Es ging im einzelnen um Parallel Studio, Cilk, Ct und daten-optimierte Intel-Compiler. Zu Parallel Studio hat er wohl nur so viel verraten, dass die nächste Version der Parallelisierungssuite für das gestern vorgestellte Visual Studio 2010 optimiert sein wird.

Mit der Übernahme von Cilk im Sommer 2009 hat sich Intel großes Know-how in Sachen task-basiertes Multithreading ins Haus geholt. Gerade sind Cilk- und Intel-Ingenieure dabei, ihre Produkte mehr und mehr zu verschmelzen, sodass in Zukunft noch eine ganze Menge aus dieser gemeinsamen Schmiede zu erwarten ist.

Aber auch mit der Ct-Technik geht es weiter voran, wie Reinders in seinem Vortrag darstellte. Ct basiert auf einem daten-konzentrischen Ansatz und soll die Methoden der Parallelprogrammierung in diesem Bereich maßgeblich verändern. Dazu gehören neue Techniken wie SWAR-Vektorisierung (SIMD within a register), die Unterstützung künftiger Hybridprozessoren und vieles mehr.

>> Den Rest des Originalbeitrags lesen …

Lag der Schwerpunkt 2009 auf der Parallelprogrammierung (es stand ja das Intel Parallel Studio kurz vor der Veröffentlichung), beschäftigt sich die iSTEP in diesem Jahr mit einer ganzen Reihe interessanter Themen. Dazu gehört natürlich eine genauere Betrachtung von Visual Studio 2010 (was ja bald auf den Markt kommt). Diesen Part wird unser guter Bekannter Steve Teixeira übernehmen, der zu den Vätern von VS 2010 gehört.

Aber auch über die generellen Probleme der Parallelprogrammierung wird zu reden sein. So verschafft David Norfolk von Bloor Research allen Anwesenden einen guten Überblick zum Thema “Mainstream Market” und wird hoffentlich die Frage beantworten, wohin die Reise geht und was Software-Entwickler in Sachen Multicore-Programmierung künftig beachten sollten.

Wenn Alexandre Jenny die Bühne betritt, wird es pragmatisch. Monsieur Jenny ist Gründer und CEO von Kolor, einem französischen Software-Unternehmen, das sich auf die Erstellung von Panoramabildern spezialisiert hat (und das seit 2004). Schon seit dieser Zeit sind Alexandre und sein Team äußert penibel darauf bedacht, mithilfe fest definierter Richtlinien das Multithreaden ihrer Software-Produkte bereits vom ersten Tag an permanent zu verbessern. Und das wohl mit großem Erfolg: Mithilfe ihrer Software gelang es Kolor, Paris in Form eines 26-Gigapixel-Bildes rundum abzubilden. Was hierfür alles notwendig ist und war, wird Alexendre eigens auf der iSTEP erzählen.

Nach dieser eher konsumer-lastigen Einlage wird es dann richtig ernst: Hugo R. Falter von der ParTec Cluster Competence Center GmbH wird darüber berichten, wie Intel, das Jülicher Supercomputing Center und seine Firma gemeinsam einen Supercomputer mit allem Schnipp und Schnapp konzipiert, gebaut und zum Laufen gebracht haben. Das ist sicherlich nichts für Weicheier! Und mit Christian Terboven von der Uni Aachen geht es dann ganz ähnlich weiter: In seinem Vortrag geht es um das Thema High-Performance Computing und darum, welche Tools notwendig sind, um ein Höchstmaß an Parallelität zu erreichen. Bestimmt auch sehr interessant, aber ohne Vorwissen steigt man wohl in Minute 3 aus.

Der dritte Abschnitt der Intel-Konference beschäftigt sich dann mit ganz anderen, aber nicht minder interessanten Dingen: Wohin geht es mit dem mobilen Markt? Uli Dumschat von Intel wird in seinem Vortrag intensiv auf die Frage eingehen, wie sich mit der Entwicklung neuer Software-Anwendungen für Netbook, Smartphone und Co. Geld verdienen lässt und was Intel damit zu tun hat. Ich verrate sicherlich nicht zu viel, wenn ich mutmaße, das Uli eine Menge über IADP, AppUp und MeeGo erzählen wird.

Als abschließender Redner wird dann Philip Ling in eine ähnliche Richtung gehen, wenngleich viel technischer. Sein Fokus liegt auf Embedded Systemen und wo er Chancen und Potenziale in diesem Markt sieht. Es geht also im In-Car-Entertainment und ähnliche Dinge – Philip wird letztendlich also auch über Intel Atom, MeeGo und Co reden.

Ach ja: Die Intel iSTEP 2010 Software Conference findet dieses Jahr am 13. April im wunderschönen Barcelona statt. Ich selbst werde zwar nicht vor Ort sein (mich zieht es auf die Internet World im genauso schönen München), aber die britischen KollegInnen des SoftTalk-Blog werden auf der Konferenz zugegen sein und in Bild, Wort und Ton berichten. Da werde ich es mir natürlich nicht nehmen lassen, die interessantesten Erkenntnisse hier zu bloggen. So, stay tuned …

• Funktionale Programmierung in C# 3.0 (Oliver Sturm)
• Anpassbare Anwendungen mit Windows Workflow 4 (Dariusz Paris von Microsoft)
• Intel Parallel Studio mit .NET und Visual Studio (Mario Deilmann von Intel)
• Debugging in Deep mit VS2010 und WinDbg (Gregor Biswanger)
• Parallelprogrammierung mit der TPL (Bernd Marquardt)
• und viele andere

Das ist nur das vorläufige Programm. Der ganze Tag besteht aus vier parallelen Teilen, in denen insgesamt 24 Vorträge plus Auftaktrede und fünf Lunch-Sessions stattfinden sollen. Da könnt ihr euch auf einiges gefasst machen.

Und damit der Tag nicht nur aus Arbeit besteht, beginnt um etwa halb sieben der unterhaltsame Teil der Dotnet Cologne mit Verlosung und anschließender Grillparty (hoffentlich passt das Wetter). Müst ihr da nicht dabei sein? Doch, ich finde schon. Ihr solltet euch allerdings beeilen, denn so richtig viele Plätze gibt es nicht mehr (es ist von etwa 50 die Rede). Also, wir sehen uns, oder?!

Leider fehlt sein Alter Ego, Ralf Westphal, dafür wird ihm aber ein erfahrener Software-Spezialist zur Seite gestellt, nämlich Volker Jungbluth, der seit 1988 der IT-Branche angehört und sogar sein eigenes ERP-System besitzt. Beide Referenten werden in insgesamt vier Sessions ihr geballtes Wissen preisgeben und über folgende Themen sprechen:

• Parallelisierung von nativem Code
• Parallelisierung mit Managed Code
• Parallelisierung im OLTP-Alltag
• Parallelisierung von Berechnungen mit OpenMP

Die Vorträge sind jeweils 75 Minuten lang und gehen fundiert auf die einzelnen Themen ein (eine Themenübersicht gibt es in diesem Programmflyer). Worauf wartet ihr also noch? Da heißt es sich schnell anmelden, denn der frühe Vogel spart bis zum 11. Mai 100 Euro, zahlt also bis dahin nur 399 Euro, nach diesem Stichtag sind es 499 Euro.

Ach ja: Die Keynote-Session wird wohl von Intel gehalten. Da gibt es bestimmt auch wieder eine ganze Menge zu hören …

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!

Nun ist es aber leider so, dass kaum ein Spiel den Zugriff auf diese Dienste implementiert hat, was jedoch mit ein paar Codezeilen an der richtigen Stelle im Quellcode des Spiels problemlos zu machen ist. Sagt zumindest Mitchell Lum von Intel, der in seinem Blogpost anhand eines C#-Beispiels zeigt, wie man aus dem laufenden Spiel heraus twittern kann. Das ist übrigens nicht nur für Multiplayer ein echter Mehrwert, sondern auch für Spieleentwickler, die auf diesem Weg den Bekanntheitsgrad ihrer Titel mithilfe von Twitter erhöhen können.

Dann schaut euch den Blogbeitrag samt Codebeispiel einfach mal in Ruhe an.

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.

Was für den August galt, traf auf den September im selben Maße zu: War ich im Vormonat auf der Games Developer Conference, so verschlug mich der neunte Monat des Jahres in das wundervolle San Francisco, wo ich eine ganze Woche auf Intel-Kosten verweilen durfte. Es ging natürlich vorwiegend um die Intel-eigene Entwicklerkonferenz IDF, wo ich mich mit zwei wesentlichen Themenschwerpunkten beschäftigte: Multicore und Netbooks. So besuchte ich unter anderem die Techsessions Software-Tools für skalierende Apps, Parallel Computing mit .NET 4 und Visual Studio 2010, Moblin Technical Overview, Netbook-Ecosysteme und Anwendungsmodelle und sammelte erste Informationen zum geplanten Intel App Store.

Der September und die IDF-Berichterstattung deuteten es bereits an: Das Software Dev Blog wird sich neben der Parallelprogrammierung in Zukunft auch mit dem Thema Netbooks, Atom-Prozessor und Co. beschäftigen. Und so verlagerten sich die Blogbeiträge im Oktober mehr und mehr in diese Richtung. So ging es um die Frage, was beim Intel Atom Developer Program alles zu beachten ist, wer eigentlich den App Store braucht und was das Intel App Store SDK wohl leisten wird. Daneben wartete im Oktober ein weiteres Event auf uns: das mobiledevecamp Munich 2009, das sich an Software-Entwickler mobiler Anwendungen richtete und das in den heiligen Intel-Hallen zu Feldkirchen stattfand. Dort waren rund 80 Leute zugegen (unter anderem Martin Mohring von der Liunux Foundation) und es war insgesamt eine wirklich gute Veranstaltung. Ansonsten fand der erste Intel Blogger Day statt und das Software Dev Blog wurde genau ein Jahr alt.

Im November ging es noch mal auf Reisen, dieses Mal nach Berlin auf die Microsoft Tech-Ed Europe 2009. Auf dieser Entwickler- und Business-Konferenz trafen sich rund 8.000 Menschen, um sich umfassend über die neuesten Microsoft-Technologien zu informieren. Intel war natürlich auch vor Ort, und so habe ich wieder gemeinsam mit Tom viele schöne Videos nebst den passenden Blogbeiträgen erstellt und verfasst. So haben wir mit Steve Teixeira über die Parallelprogrammierung aus Microsoft-Sicht geplaudert, uns von Rami Radi erklären lassen, wie .NET-Entwickler von Multithreading profitieren und haben gelernt, wie die Zukunft der Parallelprogrammierung aussehen wird. Aber es gab auch Neues von Intel in Sachen Multicore, und zwar in Form der Cloud-Testumgebung Intel Parallel Universe.

Der Dezember stand wieder eher im Zeichen des Intel App Store und des zugehörigen Intel Atom Developer Program. Aber es ging auch um Moblin, um die sieben Schritte bis zur ersten eigenen App im Intel App Store, um ein neues Buch zum Thema Parallelprogrammierung unter .NET und um Pine Trail.

Und worauf können wir uns für 2010 einstellen? Nun, während der CES in Las Vegas wird Intel wohl seinen App Store vorstellen. Ende Januar wird Intel dann auf den M-Days mit eigenen Stand vertreten sein und über das Intel Atom Developer Program und den App Store berichten. Apropos Stand: auf der Mobile World Conference in Barcelona wird Intel ebenfalls vor Ort sein – und damit auch ich. Ansonsten werden wir viele neue Dinge rund um Netbook-Apps und Co. zu sehen bekommen. Und die Games Developer Conference 2010 in Köln wird uns sicherlich auch wieder erwarten.

Der Mai stand ganz im Zeichen der Ankündigungen: So war die Geburtsstunde des deutschsprachigen Intel Onlineshops für den Mittelstand zu vermelden, aber auch die Entwicklersuite Parallel Studio erblickte das Licht der digitalen Welt. Ansonsten war der Mai eher ruhig aus Blogsicht. Daher war ein wenig Zeit für Surftipps, für die Vorstellung eines Softwaretools für mobile Spieleentwickler und für eine genauere Betrachtung, was der Parallel Advisor Lite zu leisten imstande ist.

Was dem Mai an Events beziehungsweise an deren Ankündigungen fehlte, holte der Juni direkt wieder nach. So verwies ich auf die Exasol Roadshow, die es Anfang Juli nach München verschlagen sollte. Aber auch die Intel-Microsoft-Techtalks und das GameCamp Munich 2009 waren mir entsprechende Hinweise wert. Ansonsten kam die Firma Maxon zu Wort, die mir verriet, warum Cinema 4D auf Multicore-Plattformen so leistungsstark ist.

Anfang Juli stattete ich der Intel-Außenstelle Ulm einen Kurzbesuch ab. Was ich von dort mitnahm war vor allem eins: Aus Ulm kommen grafisch orientierte Linux-Debugger, mit denen sich sequenziell und parallel programmierte Anwendungen sehr komfortabel testen lassen. Bemerkenswert fand ich im Juli aber auch diverse Einsichten: Warum Colin McRae DiRT 2 so geil auf einem Multicore-Rechner aussieht, warum Demigod auch auf Notebooks spielbar ist und warum Empire: Total War auf Notebooks gut läuft. Daneben gab es Infos zu Tools wie den Visual Studio: Parallel Debugger Extensions, Videosessions der TechTalks mit Intel und Microsoft und Screencasts zur Parallelprogrammierung unter .NET 4.

Der August stand ganz im Zeichen der Games Developer Conference, die im Gegensatz zum letzten Jahr in Köln vor der GamesCom stattfand. Auch dorthin reiste ich natürlich, gemeinsam mit Tom, mit dem ich schon seit längeren Videointerviews und ähnliche Dinge drehe und auf Youtube stelle. So lernten wir auf der GDC09 eine ganze Menge: Warum die nächste CryEngine erst 2012 kommt, warum CPUs für Spieleentwickler wichtig sind, wie Intel Parallel Studio funktioniert, wie man Spieletitel für integrierte Grafikchips optimiert und vieles mehr.

Um das Ganze besser konsumierbar zu machen, wird die Rückschau 2009 als Trilogie verfasst sein, wobei der letzte Teil auch ein wenig in die Zukunft blicken wird. Also dann mal los.

Der Januar begann traditionsgemäß mit der OOP, die im Messezentrum zu München stattfand. Dort trafen sich an fünf Tagen Software-Entwickler aus ganz Deutschland (und darüber hinaus), um über sämtliche Aspekte der objektorientierten Programmierung zu reden. Da Intel einer der Sponsoren dieses großen Events war, kam mir die Rolle des OOP-Berichterstatters zu. Es gab eine ganze Menge zu bloggen: über die Multicore-Programmierung, über 12 Thesen zu diesem Thema und über die Parallelprogrammierung im .NET-Umfeld, woraus ein umfassender Dreiteiler entstand (Teil 1, Teil 2 und Teil 3). Daneben hielt der Januar Blogposts zu der Frage parat, warum DivX, Nik Software und Crysis so gut auf Multicore-Prozessoren skalieren.

Der Februar ließ bereits erahnen, was die Multicore-Entwicklergemeinde im Jahr 2009 in Sachen Intel-Tools zu erwarten hatte: die Parallelisierungssuite Parallel Studio warf erste Schatten voraus, die im Laufe der Zeit immer länger werden sollten. In vier Blogbeiträgen wurden die Fähigkeiten dieses Visual-Studio-Plugins näher beleuchtet (Teil 1, Teil 2, Teil 3 und Teil 4). Der Februar war ohnehin sehr tool-lastig: So ging es unter anderem um hochoptimierte Software-Bibliotheken für die Parallelprogrammierung, um den Concurrency Checker und den Thread Profiler. Events fanden aus Blogsicht im Februar keine statt.

Der März begann mit einer Art Ritterschlag: das Entwicklerportal MSDN, auf dem Microsoft seine Community mit neuesten Infos und Tools versorgt, spendierte dem Thema Parallelprogrammierung eine deutschsprachige Sektion und band das Software Dev Blog prominent an diversen Stellen ein. Das nahm ich natürlich zum Anlass, einen Vierteiler zum Thema .NET-Threads zu veröffentlichen (Teil 1, Teil 2, Teil 3, Teil 4). In Sachen Events gab es auch wieder etwas zu vermelden, und zwar in Form von Vorschauen: auf die Intel Software Conference, auf den prio.powerday, die Games Developer Conference und die Eurographics 2009.

Der April war wieder sehr event-lastig, nämlich in Form der Intel Software Conference 2009 (ISC09) und des prio-powerday 2009 “Multicore-Programmierung im .NET-Umfeld”. Auf der ISC09 ging es unter anderem um die Parallelprogrammierung für den Mainstream, um Microsoft und die parallele Programmierung und natürlich um Parallel Studio. Und weil der April noch nicht genug hatte, folgte kurz nach der ISC09 der prio.powerday 2009, auf dem Dinge wie das Multithreading mit .NET-Bordmitteln besprochen wurden, aber auch die Parallele Programmierung unter .NET 3.5 und die Microsoft Concurrency Coordination Runtime.

Ach ja: Bis Ende des Jahres wird es hier noch den ultimativen Jahresrückblick geben. Also, freut euch schon mal drauf.

Sein Titel (also der des Buches): “Parallel Computing in .NET”. Sein Autor: Marc André Zhou. Sein Umfang: rund 360 Seiten. Seine ISBN: 978-3-86802-038-0. Seine Mission: Wie mache ich dotNET-Entwicklern klar, dass sie von der sequentiellen Programmierung umsteigen sollten auf die parallele. So gesehen finde ich den Titel ein wenig unglücklich gewählt, wenngleich es in dem Buch natürlich auch um Parallel Computing geht. Doch zuvorderst sollen die Leser dieses gedruckten Leitfadens etwas über Multithreaden und Co. lernen.

Und hierfür hat der Autor wirklich sehr viel an Informationen zusammengetragen. Das beginnt mit einer kleinen Aufklärungsrunde in Sachen Parallel Computing (sic!), die sogar die parallelen Programmiermodelle betrachtet. Anschließend wird es ein wenig theoretisch, indem Zhou so Dinge wie das Amdahlsche und das Gustafson-Gesetz betrachtet. Das hilft auf jeden Fall für ein grundsätzliches Verständnis, wann die Parallelprogrammierung sinnvoll ist – und wann nicht.

Nach weiteren allgemeinen Informationen rund um die Regeln des Parallel Computing, aber auch des Projektmanagement und den Modellierungsmöglichkeiten geht es dann nahtlos über in das Basiswissen rund um Threads unter .NET. Dies ist jedoch schon wieder fast veraltet, denn mit der Einführung von .NET 4.0 wird kein Mensch mehr von .NET-Threads und deren manuellem Erstellen reden.

Dies weiß aber auch der Autor, und so betrachtet er natürlich auch die kommenden Techniken und Tools wie die CLR-Threadpools, die Task Parallel Library, PLINQ,  Parallel Computing/Programming mithilfe von Visual Studio 2010 und die Concurrency and Coordination Runtime im Detail. Und den Abschluss des Buches bildet eine genauere Betrachtung möglicher zukünftiger Programmiermodelle: Axum und Software Transaction Memory.

Fazit: “Parallel Computing in .NET” ist sicherlich eine gute Quelle für alle, die mehr wissen wollen zum Thema Parallelprogrammierung mithilfe des .NET-Frameworks. Es zeigt anschaulich und sehr detailliert, wohin die Reise gehen wird und was künftige Parallelprogrammierer erwartet, vor allem mit .NET 4.0. Anhand geeigneter Codebeispiele werden wohl selbst unerfahrene Multithread-Entwickler einen Zugang zu diesem nicht ganz trivialen Thema finden. Und für alle, die mehr wissen wollen zu diesem Buch, gibt es auf der zugehörigen Webseite die passenden Infos.

Surftipp: Falls ihr euch für die Quellcodebeispiele des Buches interessiert, solltet ihr mal auf diesen Link klicken.

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

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

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

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

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

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

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

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

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

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

Nur so viel: Ct soll noch in diesem Jahr als Beta verfügbar sein und Software-Entwicklern dabei helfen, ihre Anwendungen noch eleganter zu parallelisieren als bisher. Und genau dieses Bestreben verfolgen auch die Jungs von Rapidmind. Das dürfte wohl der wesentliche Grund gewesen sein, warum Intel und Rapidmind seit Ende August gemeinsame Sache machen.

Aber am besten lassen wir Stefeanus, Michal und Anwar selbst zu Wort kommen …

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

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

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

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

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

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

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

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

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

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

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

Am 4. November ging es mit der ersten Vorfreude los, die einen Tag später in einem Ausblick mündete, was es auf der TechEd Europe 2009 alles zum Thema Parallelprogrammierung zu sehen gibt. Diese Frage habe ich tags drauf konkretisiert und mir mal einen Teil des TechEd-Programms angesehen. Da wurde schnell klar: Das Thema Parallelprogrammierung und Multithreading erfährt endlich die Wertschätzung, die notwendig ist, um den ein oder anderen Software-Entwickler wachzurütteln und zu sagen: Leute, denkt parallel!

Am 9. November war es dann soweit: Die Microsoft TechEd Europe 2009 öffnete ihre Pforten und wir waren mittendrin. Da war es natürlich mehr recht als billig, mit ein wenig Orgakram darauf hinzuweisen, wo der Intel-Stand liegt und was es alles dort zu sehen gibt. Tom hat sich währenddessen mit seiner Videokamera auf die Suche nach ersten Eindrücken gemacht – und wurde fündig.

Am zweiten Tag habe ich diverse Techsessions besucht, aus denen zum einen Live-Twittering resultierte und zum anderen ein sehr interessantes Videointerview mit Steve Teixeira von Microsoft, in dem er mir erzählt hat, was Software-Entwickler von .NET 4 in Sachen Parallelprogrammierung erwarten können. Am selben Tag gab es übrigens die erste von drei Parallel-Studio-Sessions, die Ralph direkt neben dem Intel-Stand gehalten hat. Anschließend fand die von vielen (und ich meine: viele!) sehnlichst erwartete Netbook-Verlosung statt, die natürlich einen glücklichen Gewinner ermittelte.

Am selben Tag saß ich mit ein paar anderen Bloggern in einer Telefonkonferenz, in der Intel neueste Infos rund um das Intel Atom Developer Program (IADP) verraten hat. Und um IADP ging es auf der TechEd Europe 2009 seitens Intel schließlich auch.

Tag drei begann sehr pünktlich und sehr technisch, und das in Form einer Präsentation von Rami Radi, der sich bei Intel um das Thema Parallelprogrammierung kümmert. Ramis Techsession dauerte 75 Minuten und war vollgepackt mit interessanten Einsichten, was Software-Entwickler alles tun sollten, um ihre Anwendungen multicore-tauglich zu machen. Und das gilt natürlich für alle: für native Programmiersprachen und für managed Code.

Auf Basis seiner Session entstand übrigens die Idee, einen Video-Workshop online zu stellen, mit dem .NET-Entwickler lernen können, wie sich ihre Anwendungen mithilfe des Intel-Tools VTune Performance Analyzer beschleunigen lassen.

Am 11. November besuchte ich die sehr lebhafte Diskussion mit Tiberiu Covaci, in der es um die Zukunft der Parallelprogrammierung ging. Hinterher haben wir Tiberiu vor die Kamera gezerrt und ein wenig mit ihm geplaudert. Den Abschluss unserer TechEd-Reise stellte dann eine höchst unterhaltsame und informative Präsentation von Ralf Westphal dar, der mithilfe der Concurrency Coordination Runtime (CCR) gezeigt hat, wie sich asynchrones Programmieren höchst positiv auf das Laufzeitverhalten von .NET-Anwendungen auswirkt. Hinterher haben wir Ralf noch ein paar Fragen gestellt.

Die erste interessante Aussage, die Ralf während seiner 75-Minuten-Session abgefeuert hat, war die Erkenntnis, dass Software-Entwickler sich selbst um das Parallelisieren ihrer Anwendungen kümmern müssen und dies nicht nur dem Betriebssystem oder anderen Instanzen überlassen dürfen. Ein weiterer Satz war nicht ganz überraschend und auch nicht neu, dafür umso wichtiger: “The free lunch is over!” Dieser Ausspruch stammt übrigens nicht von Ralf, sondern von Herb Sutter, der das bereits 2005 formuliert hat. Die Grundaussage dahinter lautet:

Künftige Prozessoren werden nicht mehr unendlich schneller, sind dafür mit immer mehr CPU-Kernen ausgestattet. Daher müssen Programmierer umdenken, um ihre Anwendungen in Zukunft zu beschleunigen.

Schenkt man Ralf Glauben (und das tue ich), steht die Parallelprogrammierung im Wesentlichen für folgende Dinge:

Reduced latency, higher performance, hiding latency, higher responsivness and increased throughput.

Dann folgten zwei eher rhetorische Fragen, deren Antworten man mit ein wenig Nachdenken sehr schnell selbst beantworten konnte:

Does firing up as many threads as cores are available help to accelerate apps? No, because this will cause threads waiting!

Does firing up as many threads as needed helps to accelerate apps? No, because it doesn’t scale!

Mit einem sehr schönen Vergleich leitete Ralf dann den Abschnitt “CCR” ein, indem er die digitale Kommunikation via E-Mail mit der asynchronen Programmierung verglich. Denn wie beim Verteilen von Aufgaben per Mail erfolgt das Ausführen von Tasks mithilfe der CCR genauso asynchron, indem ständig priorisiert und verteilt wird. Sehr anschaulich, oder?!

Dazu passen auch folgende Aussagen:

Concurrency Coordination Runtime (CCR) helps to let data flow around and make thus asynchronous apps possible.

Parallel Computing is all about cooperative multitasking where you have to think about small processes and steps.

Anschließend folgte die sehr anschauliche Demo, die den Einsatz der CCR in Form eines Programmierbeispiels zeigte. Dies hier wiederzugeben, wäre ein wenig zu umfangreich und auch kaum hilfreich. Allerdings stellt Microsoft angeblich sämtliche Sessions als Webcast online. Sobald Ralfs verfügbar ist, werde ich sie hier verlinken.

Natürlich haben wir Ralf nicht gehen lassen, ohne ihm drei Fragen zu stellen, die mit seinen Vorträgen auf der TechEd zu tun haben, mit der CCR und einer ganz exklusiven Geschichte, die er am Ende seiner Session zum ersten Mal in der Öffentlichkeit vorgestellt hat. Sobald das Videointerview online ist, werden ich es hier reinstellen.

Sein Vortrag hatte allerdings eher den Charakter eines technischen Workshops, indem er selbst zunächst eine Menge zum Thema Intel, Microsoft und Multicore-Shift inklusive .NET 4 und Visual Studio 2010 erzählt hat. Auszüge gefällig?

TPL of .NET 4 delivers the right number of threads regarding the available number of cores/threads.

Needs around 200.000 instruction cycles to create a thread and 100.000 for releasing it again. As a developer you have take this into account!

TPL delivers several parallel classes like Parallel.For() and Parallel.Invoke which abstracts threads to tasks.

Visual Studio 2010 will deliver the appropriate debugger tools for parallelized applications.

Was seiner Techsession allerdings ein wenig fehlte war der Blick in seine Glaskugel, die uns Anwesenden etwas über die Zukunft der Parallelprogrammierung hätte erzählen können. Zumindest war ich genau aus diesem Grund in seinem Vortrag. Das ließ sich allerdings ganz schnell nachholen, indem wir unsere Videokamera aufgebaut und Tiberiu drei schlaue Fragen gestellt haben. Die erste handelt vom Inhalt seiner Präsentation, Nummer zwei beschäftigt sich mit seiner Podiumsdiskussion vom Montag und mit der Beantwortung von Frage drei ließ er uns in die Zukunft der Parallelprogrammierung blicken.

Nur so viel dazu: Laut Tiberiu müssen sich Software-Entwickler ab sofort mit Multithreading und Co. auseinander setzen, denn der Multicore-Shift hat schon längst begonnen. Und den Rest schaut ihr euch am besten selbst an, sobald unser Videointerview fertig und online ist.

Update: Das Video ist fertig!

Zunächst einmal muss festgehalten werden, dass die Session genauso gut besucht war wie die gestrige von Steve Teixeira. Darüber hinaus wurde schnell klar, dass die meisten Anwesenden weder wussten, dass Intel noch etwas anderes produziert als Mikroprozessoren, noch die Intel-Tools wie VTune Performance Analyzer kannten (was angesichts des “weder” keine Überrraschung war).

Ramis Präsentation befasste sich mit drei Kerngebieten: Intels aktuelle und zukünftige Mikroprozessor-Architekturen, .NET-4-Verbesserungen in Sachen Multithreading und wie Intel-Tools wie der besagte VTune Performance Analyzer Software-Entwicklern helfen können, ihre Apps auf Korrekheit hin zu überprüfen. Zu diesem Behufe sagte Rami einige bemerkenswerte Dinge:

Moore’s law doesn’t help software developers anymore as frequencies aren’t going up anymore. The good news: the number of core does!

With Nehalem you get Non Uniform Memory Acess (NUMA) which connects every CPU and memory to each other which has huge advantages.

Come to Intel booth in hall 4.2 to see one of the first desktop PCs which is able to run 128 threads in parallel!

Multithreading is not equal parallelism!

Poor scaling .NET applications can be powered up with the help of Intel VTune Performance Analyzer and Visual Studio 2010 / .NET 4

.NET 4 provides the Background Garbage Collection which speeds up managed code significantly.

Worker stealing within .NET 4 will help to achieve better multithreaded balanced managed applications.

VTune profiles and samples .NET applications in order to find critical code sections where a lot of computing time is being wasted

Vtune also helps identifying false sharing problems. Means VTune will detect and solve cache line misses.

To eliminate  false sharing problems helps to speed up your .NET apps on 8 core system by 70x!

Sehr anschaulich und beeindruckend war auch die Maze-Solving-Demo, die Rami dabei hatte. Ziel solch eines Maze Solvers ist das Aufspüren des optimalen Pfades innerhalb einer zweidimensionalen Umgebung, wie dies beispielsweise in Logistikanwendungen häufig notwendig ist. Um die Leistungsfähigkeit von .NET 4 und Multithreading zu demonstrieren, startete Rami die Demo zunächst unter .NET 3.5 im seriellen Modus. Das Problem wurde unter .NET 3.5 in 14 Sekunden gelöst, unter .NET 4 hingegen in 12, und das nur wegen der architekturellen Verbesserungen im .NET-4-Framework. Und klar, dass die Multithreading-Variante in .NET 4 das Problem blitzschnell in wenigen Sekunden löste.

Spannend fand ich auch seine Ausführungen bezüglich VTune und .NET. Denn dieses Tool wird vorwiegend zur Fehlersuche in nativ programmierten Anwendungen eingesetzt. Umso überraschender war die Erkenntnis, dass VTune auch .NET-Entwicklern bei ihrer Arbeit helfen kann. Hierzu erstellt VTune ein Profil der laufenden Anwendung und generiert dabei eine große Zahl an Samples, die dann kumuliert und gewichtet werden. Das Ergebnis zeigt auf einen Blick, wo sich mögliche Hotspots innerhalb des Codes befinden.

Natürlich hatten wir während Ramis Präsentation die Kamera aufgebaut und diese bis zum Schluss mitlaufen lassen. Klar ist aber auch, dass wir daraus keinen 75-Minüter bauen. Tom schneidet gerade die besten Szenen zusammen, mischt diese mit dem Interview, das wir mit Rami nach seinem Vortrag geführt haben, und wenn das Video fertig auf Youtube steht, werden wir es hier veröffentlichen. Freut euch schon mal auf sehr anschaulichen Content.

Update: Das Video ist fertig!

Intel Parallel Studio = Amplifier + Inspector + Composer + Advisor = Multicore optimization

Parallel Advisor helps you to parallelize your native code. But from 2010 onwards only.

With Parallel Inspector you find memory errors before they happen. Works on serial AND threaded code.

Intel Parallel Amplifier is a child of VTune Performance Analyzer, but easier and more intuitively to use. Profile you parallel code.

On http://wwwintel.com/go/para… you’ll find more information about Parallel Studio and more.

Nach der Parallel-Studio-Session gab es das dann das lang ersehnte Netbook, ein Sony Vaio. Sehr schickes Teil. Der Durchgang zwischen Theater und Intel-Stand war entsprechend für eine kurze Zeitspanne komplett verstopft. Kein Wunder: Netbooks sind gerade der große Renner.

Für alle, die nicht dabei sein konnten, haben wir Ralphs Vortrag und die Netbook-Verlosung mit unserer JVC-Kamera auf SD-Karte gespeichert. Sobald Tom die besten Bilder zusammengeschnitten hat, geht das Video hier online.

Update: Hier ist das Video. Viel Spaß damit!

So wie heute morgen um 9:00 Uhr in der Früh, was aber die anwesenden Software-Entwickler nicht davon abgehalten hat, den Raum bis auf den letzten Platz zu füllen. Das zeigt zweierlei: Erstens hat das Thema Multithreading viele Leute schon erreicht, und zweitens besteht offensichtlich noch eine Menge an Informationsbedarf. Und da ist Steve genau der richtige, um vorhandene Wissenslücken zu füllen.

Für alle, die es nicht mitbekommen haben: Ich saß in der Session und habe mir die Seele aus dem Leib getwittert. Ein paar Kostproben gefällig?

First demo: LINQ versus PLINQ. Guess who is faster? Got it?! Yes, PLINQ is 3.3x faster.

The only difference between LINQ & PLINQ is a little “AsParallel()”. Very easy, very intuitive!

ParallelEnumarable() fits perfectly for parallel computing with huge data. Think of financial applications, e.g.

There’s one important advice by Steve: Don’t use threads but tasks. .NET 4 is supporting with Parallel.Invoke() e.g.

With .NET 4 you can delay tasks in order to run them later as soon you need them.

Diese und andere Aussagen ergaben ein klares Bild: .NET 4 soll und wird die Parallelprogrammierung verbessern, und das mit einem klaren Konzept, mit Tasks statt Threads und den passenden Tools wie einem Debugger, der viele Informationen über die laufenden Threads und Tasks liefert.

Direkt nach der Session konnten wir übrigens Steve Teixeira dazu überreden, uns vor der Kamera ein paar Fragen zu beantworten. Kollege Papadhimas ist gerade am Schnitt dran. Sobald das Video fertig und auf Youtube gestellt ist, kommt hier der Embedcode rein. Damit ihr auch etwas davon habt.

Update: Das Video ist fertig geschnitten, gerendert und auf Youtube. Und hier. So, Film ab.

• Steve Teixeira wird morgen früh (Di, 9:00) etwas zu “Parallel Computing for Managed Developers” erzählen. Hoffentlich bekommen wir Steve hinterher für ein Interview vor die Kamera.
• Um 15:15 Uhr geht es dann um das Thema HPC und Virtualisierung. Auch hier planen wir ein anschließendes Videointerview.
• Intel-Kollege Rami, der am Mittwoch seine Techsession hat, wird uns in seiner Demo zeigen, wie Managed Code mithilfe von VTune optimiert werden kann.
• Natürlich werden wir auch Bilder von der Parallel-Studio-Session inklusive Netbook-Verlosung zeigen.
• Am Mittwoch hat dann Rami seine besagte Techsession. Hinterher stellen wir im ein paar schlaue Fragen.
• Um 10:15 Uhr geht es direkt weiter mit F# und dessen parallelen Fähigkeiten. Hinterher gibt’s hoffentlich ein Videochat mit Donald Syme.
• Tiberiu Covaci hält um 12:20 Uhr seinen Vortrag mit dem Titel “The Future of Parallel Programming”. Anschließend werden wir Tiberiu zu seinen diversen Techsessions befragen. Auch zu denen, die wir heute Morgen leider nicht besuchen konnten.
• Und falls ihr nochmals die 15-Minuten-Präsentation samt Netbook-Verlosung sehen wollt: Am Mittwoch ist wieder Gelegenheit dazu.
• Der Donnerstag beginnt mit einer Parallelsession mit dem Titel “Going Parallel for a Living: Introduction to the Concurrency Coordination Runtime” des lieben Kollegen Ralf Westphal. Mal sehen, ob er uns auch vor der Kamera etwas erzählt.
• Um 15:15 Uhr ist Steve Teixeira noch mal dran, und zwar mit seiner Session “Building High Performance Parallel Software”. Ob Steve sich zweimal von uns interviewen lässt?
• Natürlich gibt es auch am Donnerstag die fast schon lieb gewonnene 15-Minuten-Session inklusive Netbook-Vergabe. Aber diesmal schenken wir uns das vielleicht. Wir wollen ja niemanden langweilen.
• Und klar, dass die Intel-Kollegin Beatrice noch zu Wort kommt. Sie will nämlich unbedingt etwas zum Intel Atom Developer Program erzählen.

So, und nach so vielen Programmankündigungen kommen jetzt endlich die Impressionen aus Berlin. Film ab!

Bevor ich es ganz vergesse, folgen hier noch ein paar organisatorische Dinge: Der Intel-Stand, an dem ihr mich und die Kollegen treffen könnt, befindet sich in Halle 4.2 und liegt von der Halle 7 kommend direkt am Eingang. Das ist die so genannten Visual Studio Partner Zone. Dort gibt es unter anderem eine Menge nützliche und erhellende Infos rund um das neue Intel Atom Developer Program, das Software-Entwicklern dabei helfen soll, windows- und moblin-basierte Anwendungen speziell für Netbooks zu entwickeln und diese zu einem späteren Zeitpunkt auf Netbooks zu bringen. Falls ihr euch für dieses Programm direkt am Stand registriert, gibt’s auch eine kleine Überraschung.

Darüber hinaus findet ihr eine Menge Infos rund um unser liebstes Baby, das auf den schönen Namen Intel Parallel Studio hört und in rund zwei Wochen sein Halbjähriges feiert. Falls ihr also C-/C++-Programmierer seid, Visual Studio einsetzt und eure Anwendungen threadsicher parallelisieren wollt oder einfach nur gucken wollt, ob sich besonders fiese Bugs eingeschlichen haben, die sich möglicherweise erst zur Laufzeit zeigen, ist Parallel Studio genau das richtige Tool für euch. Hier könnt ihr sogar eine Test-CD abgreifen, um euch mit Parallel Studio vertraut zu machen.

Und falls ihr ein neues Netbook wollt, solltet ihr ebenfalls am Stand V1/V2 vorbeikommen. Beantwortet ein paar Fragen, tragt eure Daten ein und schwups, ab mit der Karte in die zugehörige Losbox. Und schon gewinnt ihr vielleicht eins der schicken Teile. Die erste Verlosung ist allerdings erst morgen Nachmittag, die ausgefüllten Karten werden aber auch schon heute akzeptiert.

So, dann mach ich mich wieder auf den Weg zum Stand. Um den Monitor zu installieren, der gerade gekommen ist. Damit ihr auch besser sehen könnt, was ich twittere und blogge. Man sieht sich!

Ach ja: Auf der anderen Seite der Halle hat Intel noch einen Stand, auf dem es rund um das Thema Datacenter geht. Also alles über Servertechniken, Virtualisierung und Co. Und dort gibt es ebenfalls etwas zu gewinnen, nämlich schicke, ultradünne Notebooks. Ihr seht, ein Besuch der Halle 4.2 lohnt sich auf jeden Fall.

Wie ich ja bereits angekündigt habe, werden wir uns bevorzugt um das weite Feld der Parallelprogrammierung kümmern. Da sind zum einen die 15-Minuten-Sessions auf der großen Showbühne zu nennen, auf der Ralph und Edmund in gewohnt treffsicherer Art und Weise über Parallel Studio referieren und sagen werden, warum das Plugin für Visual Studio nicht nur zum Multithreaden taugt, sondern auch Bugs in seriell programmierten Anwendungen aufspürt und hilft, diese zu eliminieren. Und die Session von Rami werde ich mir ebenfalls nicht entgehen lassen. Der werte Kollege erzählt nämlich vom Dreigestirn Windows 7, .NET und Multicore-Optimierungen.

Dass so eine riesige Konferenz aber noch mehr zu bieten hat als Parallel Studio und Intel-Sessions, macht ein Blick in den äußerst umfangreichen Sessionplan klar. Dort finden sich unter dem Schlagwort “Parallel” ein gutes Dutzend interessanter Vorträge zum Thema Parallelprogrammierung. Die spannendsten Sessions werde ich natürlich aufsuchen und live darüber berichten (entweder in diesem Blog oder per Twitter). Und weil das noch nicht genug ist, ziehe ich mit Tom und Videocam immer wieder los, um die maßgeblichen Köpfe der TechEd mit schlauen Fragen zu konfrontieren. Aber das kennt ihr ja schon.

Ok, dann bleibt mir nur noch, uns allen eine interessante Microsoft-Konferenz zu wünschen, verknüpft mit der Hoffnung, dass nicht der ein oder andere im Trubel der Berliner Feier zu 20 Jahren Mauerfall verloren geht. Wäre doch schade …

Aber, um jetzt wieder ein bisschen ernsthafter zu werden, was wirklich parallel ist an der diesjährigen Microsoft TechEd Europe sind die vielen Sessions und Vorträge, die sich mit diesem Thema beschäftigen. Das zeigt zweierlei: Erstens wirft Visual Studio 2010 samt .NET 4 große Schatten voraus und zweitens scheinen Multithreading und Co. in den Köpfen von Microsoft angekommen zu sein. Aber das ist nicht so überraschend. Höchstens die Vehemenz, mit der die Konferenz das Thema angeht.

So gibt es beispielsweise Tiberiu Covaci (erinnert mich ein bisschen an jemanden von der Enterprise), der gleich mit mehreren Parallelsessions vertreten ist. So stellt er am Montag die ziemlich rhetorische Frage “Is the future of programming a parallel one?” (Und alle: “Yeah!”) Dabei will er unter anderem herausfinden, welche Branchengrößen den Multicore-Markt vorantreiben (wie heißen die noch mal mit dem großen I am Anfang … ?).

Am Dienstag und Mittwoch ist er dann wieder an der Reihe, und zwar mit den Sessions “Why should you care about Multi-core programming” und “The Future of Parallel Programming”. Aufmerksame Leser dieses Blogs werden wohl die erste Frage locker beantworten können, aber auch die Zukunft der Parallelprogrammierung war hier schon das ein oder andere Mal Gegenstand der Diskussion. Zusammengefasst bleibt festzuhalten, dass Tiberiu (a) sehr fleißig ist und (b) ein heißer Kandidat für unsere Videointerview-Reihe.

Aber – und das ist die gute Nachricht für Tiberiu – es gibt noch andere Fachleute auf der TechEd Europe 2009, die etwas zu dem Thema Multicore-Programmierung und Multithreading zu sagen haben. So wie Anthony Howcroft, der am Mittwoch über Microsofts SQL-Server-Projekt “Madison” referieren wird. Madison ist übrigens MPP, was für “Massively Parallel Processing” steht. Aber selben Tag wird auch unser alter Freund Steve Teixeira (sorry, Steve!) auf die Bühne klettern und wie gewohnt über das Thema Parallelprogrammierung reden. Diesmal geht es um “Parallel Computing for Managed Developers”. Wovon dort die Rede sein wird, ist klar, oder?! Sicherlich nicht um Programmierer mit eigenem Coach!

Für alle weiteren Parallel-Infos hilft es auf jeden Fall, die gut sortierte Webseite der Microsoft TechEd Europe 2009 zu besuchen. Oder ihr fahrt am besten selbst dorthin (Finger hoch: wer fährt?!). Und falls ihr keine Zeit oder keine Kohle oder sonst was habt, um selbst vor Ort zu sein, hilft ab Montag der regelmäßige Besuch dieses gut sortierten Blogs. Hier gibt es alle relevanten Infos rund um die TechEd Europe 2009 samt Videointerviews, Impressionen und vielem mehr. Also, man liest sich!

Ach ja: Intel redet natürlich auch auf der TechEd über das Thema Parallelprogrammierung. Aber das wisst ihr ja bereits …

Aber das wird uns nicht davon abhalten, unserem Job nachzugehen und vier Tage lang über folgende Dinge zu (video)bloggen (am fünften Tag wird die TechEd leider ohne uns auskommen müssen):

Wie üblich werden wir interessanten Leuten unsere HD-Cam unter die Nase halten und ihnen schlaue Fragen stellen. Natürlich gehen die Ergebnisse gleich vor Ort online und wir werden auch darüber bloggen. Hierbei erwartet alle Anwesenden eine echte Weltneuheit: Anstatt in einem kleinen, muffigen Konferenzraum zu sitzen und dort abgeschieden von der Welt vor mich hin zu schreiben, sitze ich am Intel-Stand in der Visual Studio Partner Zone und blogge dort live! Damit mir alle beim Arbeiten auch zusehen können, wird mein Geschriebenes direkt auf einen großen TV-Bildschirm übertragen, der sich in meinem Rücken (oder sonstwo) befindet. Unsere ganz persönliche Daily Soap von der TechEd Europe 2009!

Ebenfalls in Wort und Bild werden wir über die drei 15-Minuten-Sessions berichten, die die anwesenden Intel-Kollegen halten werden. Hauptthema wird Parallel Studio sein, mit dem sich seriell programmierte Anwendungen parallelisieren lassen, damit sie möglichst schnell auf Multicore-Systemen laufen. Allerdings geht es dabei nicht nur um Performance, sondern um weitere Aspekte wie Sicherheit, Effizienz und, ok, Performance.

So kümmert sich beispielsweise der Memory Checker (der Bestandteil des Parallel Inspector ist) um solch unschöne Dinge wie Speicherlecks, die zur Laufzeit eines Programms unerwartet auftreten können. Derartige Bugs findet man mit den herkömmlichen Debuggertools nur sehr schwer.

Darüber hinaus lässt sich mithilfe des Parallel Amplifiers die Leistungsfähigkeit seriell programmierter Anwendungen steigern, indem man zeitkritische Pfade und Hotspots aufspürt. Gerade Schleifenkonstrukte sind eine beliebte Fehlerquelle, die oft mehr Rechenzeit verbraten als wirklich erforderlich wäre.

Jenseits dieser Multicore-Sessions gibt sich Rami Radi von Intel die Ehre und erzählt in seiner Techsession etwas darüber, wie man mit diversen Tipps und Tricks gleich einen dreifachen Leistungsschub erzielen kann – hinsichtlich Windows 7, .NET 4 und Intel Multicore. Dabei soll er sogar verraten, wie sich .NET-basierte Anwendungen mit dem VTune Performance Analyzer optimieren lassen. Habe ich zumindest gehört. Aber keine Sorge: Ihr werdet hier nichts verpassen.

Das kann aber nur heißen: Bookmark setzen oder RSS-Feed abonnieren oder sonst etwas und die nächsten Tage immer wieder vorbeischauen. Man liest sich!

Was aber bleibt ist die Gewissheit, dass wir wie im vergangenen Jahr mit der kompletten Ausstattung in die Hauptstadt reisen. Also mit HD-Videokamera, Schnittrechner, Notebook, Netbook und anderen technischen Spielereien. Das machen wir übrigens alles nur für euch, die ihr da draußen vor dem PC sitzt und unsere Einträge lest, weil ihr entweder selbst nicht zur Tech-Ed fahren oder einfach nur gucken wollt, was ihr alles verpasst.

Und was heißt das jetzt im Einzelnen? Nun, wir werden wieder interessante Leute wie Microsofts Steve Teixeira vor die Kamera zerren und ihnen schlaue Fragen stellen. Wir gucken uns aber auch bestimmt sämtliche Intel-Demos an, die auf der Visual Studio Partner Zone zu sehen sind (und ein bisschen mehr).

Klar ist natürlich auch, dass wir uns das Ganze nicht nur ansehen, sondern auch über all die schönen Dinge bloggen, die vom 9. bis 13. November auf der Microsoft Tech-Ed Europe 2009 passieren werden. Dass wir dabei nicht vergessen, über den Tellerrand hinauszusehen, spricht doch für sich selbst, oder?!

Außerdem über so spannende Projekte wie das Mobiledevcamp, das morgen in einer Wochen in den heiligen Hallen Intels stattfinden wird. Dort treffen sich Software-Entwickler, die für mobile Geräte die passenden Anwendungen konzipieren und schreiben. Es wird um Linux-Themen gehen (wie Moblin), aber auch um Plattformen wie Netbooks und MIDs. Wir sind schon sehr gespannt, was es alles zu sehen und zu hören gibt.

Am Mittwoch folgte dann der erste Blogger-Day, den ich gemeinsam mit Intel veranstaltet habe. Ursprünglich hatten wir sieben Leute eingeladen, von denen dann leider vier abgesagt haben (aus zugegebenermaßen nachvollziehbaren Gründen). Es blieben also drei Blogger/Entwickler, die sich mit uns an einen Tisch setzen wollten. Und ich muss sagen: Es hat sich gelohnt. Denn sowohl die zweistündige Diskussion als auch das Abendessen im Anschluss haben verschiedene Dinge gezeigt:

• Intel ist doch nicht so steif drauf, wie wohl der ein oder andere erwartet hatte!

• Das Thema Multicore-Programmierung/Multithreading wird zwar von vielen Entwicklern ernst genommen, beschäftigen tun sie sich trotzdem nicht wirklich damit.

• Neue, funktionale Programmiersprachen wie F# könnten dabei helfen, Hemmungen vor der parallel orientierten Programmierung abzubauen.

• Das Analysetool VTune Performance Analyzer versteht sich auf das Identifizieren von Flaschenhälsen und anderen Blockaden in .NET-basiertem Code (hierzu wird es bald auf diesem Sender einen ersten Workshop geben).

• Solch ein Blogger-/Entwickler-Treffen ist eine tolle Sache und sollte unbedingt wiederholt werden. Das war zumindest die einhellige Meinung aller Anwesenden, und dazu gehörten unter anderem Klaus, Albert, Tilman und Dariusz. Schade für alle anderen, die nicht dabei sein konnten.

• Wie man es plant, in solch einer illustren Runde kommt es oft anders, als man denkt. Zumindest wurde unser Vorhaben, die Veranstaltung mit einer Einführungs- und Vorstellungsrunde einzuläuten, jäh von der unmittelbar einsetzenden Diskussion torpediert. Aber ganz ehrlich: Das war auch gut so!

Na dann also bis zum nächsten Intel-B(logger)-Day!

Los ging das Bloggen für Intel am 11. August 2008, und zwar anlässlich der Spieleentwickler-Konferenz GCDC’08, die voriges Jahr noch im schönen Leipzig stattfand. Aufgrund der guten Erfahrungen und des Erfolgs vor, während und nach dieser Veranstaltung habe ich gemeinsam mit Intel das Software Dev Blog ins Leben gerufen. Die Ausrichtung war von Anfang eindeutig: Was muss ich als Software-Entwickler alles dafür tun, damit meine leistungshungrigen Anwendungen optimal auf Multicore-Prozesssoren laufen?

Dafür habe ich erst einmal die wichtigsten Tools vorgestellt, die Intel hierfür in petto hat. Namentlich sind dies Parallel Studio, VTune Performance Analyzer, Thread Checker, Intel TBB, Intel Compiler, Concurrency Checker, Thread Profiler und andere Werkzeuge. Dann kam Event Nummer 2 schon des Wegs: Microsoft Tech-Ed 2008, wo wir live gebloggt und Videos gedreht haben.

Ab Mitte Februar warf Parallel Studio dann weitere Schatten an die Wand, die ich zum Anlass nahm, mir die angekündigte Multicore-Suite genauer anzusehen. Am 27. Mai kam das Tool dann übrigens zur Welt.

Selbst Grundlagen der parallelen Programmieren kamen und kommen hier nicht zu kurz. So kann man Multithread-Konzepte kennen lernen, von fünf Multicore-Programmierregeln lernen, Programmiermethoden erforschen, mögliche Fehler umgehen, OpenMP begutachten und viele andere Dinge mehr.

Das Software Dev Blog prangert auch schon mal an, so wie die Ausbildungslücken in Sachen Multicore-Programmierung, oder loben Unis, wenn sie sich dieses Themas annehmen.

Im Laufe des zurückliegenden ersten Jahres habe ich immer wieder wichtige Menschen der Entwicklerszene zu Wort kommen lassen, so wie die Vertreter von DivX, Crytek, Nik Software, Microsoft, Cakewalk, Maxon und andere.

Natürlich begab ich mich zwischendurch einige Male auf längere und kürzere Reisen, um live von passenden Veranstaltungen zu berichten. Dazu gehörte die OOP in München (aus der sich ein .NET-Vierteiler ergab), Eurographics 2009 (auch aus München), Intel Software Conference in Salzburg, prio.powerday in München, die Exasol-Roadshow, das Gamescamp zu München, TechTalks mit Intel und Microsoft, Game Developers Conference 2009 zu Köln und kürzlich das Intel Developer Forum in San Francisco, auf dem es eine Menge Infos zu Moblin gab. Dieses Thema wird mich hier übrigens in nächster Zeit noch öfter beschäftigen.

Gefeiert wird der erste Geburtstag übrigens auf dem morgigen Intel (B)logger Day, der in … genau, München stattfindet. Happy Birthday, Blog!

• Der freiberufliche Journalist Andreas Heil beschäftigt sich während seiner Opening Keynote-Session mit den Themen Parallelisierung, Nebenläufigkeiten und den damit verbundenen Unterthemen “große Datenmengen” und “komplexe Berechnungen”.

• Siemens-Mann Michael Stal referiert über Microsoft Axum, eine agentenbasierte Koordinationssprache, mit deren Hilfe Softwaresysteme in .NET parallelisiert werden können. Im Gegensatz zu systemnahen Ansätzen wie PLINQ oder der Task Parallel Library unterstützt Axum dedizierte Architektur- und Komponenten-Designs und lässt sich prima mit weiteren .NET-Sprachen mischen.

• Ralph Westphal bringt den anwesenden Entwicklern und Softwarearchitekten die Concurrency Coordination Runtime des künftigen .NET-Frameworks ein gutes Stück näher. Dabei geht es um die Serviceorientierung im Kleinen: Nachrichten- und Datenflüsse sollen eine skalierbare Parallelität deutlich einfacher machen als bisher.

• Bernd Marquardt stellt in seinem 90-minütigen Vortrag die Parallel-Features der Programmiersprache C++ vor, die Microsoft in Form der Parallel Pattern Library (PPL) zur Verfügung stellt. Hierbei handelt es sich um einfache Konstruktionen, die Schleifen und Code-Bereiche parallelisieren sollen. Dies ist durchaus vergleichbar mit den Intel Threading Building Blocks.

• Und natürlich geht es in diversen Tracks um Microsoft Visual Studio 2010, das ab nächsten Jahr auf Basis des .NET-Frameworks 4 eine ganze Menge zum Thema Parallelprogrammierung beitragen wird.

Multithreaded programming is “hard” today

Das bedeutet für Microsoft (und Intel), Software-Entwicklern dabei zu helfen. Hierzu bieten beide (Intel und Microsoft) passende Tools, die Programmierer unterstützen. Dazu gehören laut Steve aber auch Programmiersprachen und Plattformen.

Ein kleines Schleifenbeispiel führt Steve vor, das zeigen soll, wie sich seriell programmierter Quellcode parallelisieren lässt – inklusive potenzieller Probleme.

Als Lösung für das Sortierproblem eignet sich laut Steve LINQ, das Teil von .NET 3.5 ist. Weitergesponnen bietet die parallele Version von LINQ = PLINQ eine viel bessere Lösung für Sortieralgorithmen – und mehr!

Die nächste Folie – und Steve hat eine Menge davon – zeigt den Aufbau von Visual Studio 2010. Dazu gehören Tools wie Parallel Debugger und Profiler Concurrency Analysis, Programmierungsmodelle wie PLIN!, Task Parallel Library (TPL) und mehr.

Ein paar Daten zu TPL: Es handelt sich dabei um eine parallel API mit speziellen Konstrukten wie parallel_for, parallel_invoke, critical_section (Synchronisation), task_group (Tasks), combinable<T> (Container) etc.

Jetzt folgt ein Beispiel für die anwesenden C++-Programmierer: Es zeigt eine Matrizenberechnung, genauer gesagt eine vektorbasierte Addition. Zuerst geht es um die serielle Implementierung der Rechenaufgabe, dann um die parallele mithilfe einer Lambda-Funktion und der parallel_for aus der TPL. Dabei muss man sich ernsthafte Gedanken um Race Conditions machen. Die Lösung des Problems: Es gibt mehrere Instanzen des Rückgabewerts, die am Ende addiert werden.

Die Asynchronous Agents Library eignet sich vor allem für das asynchrone Ausführung paralleler Quellcode-Abschnitte. Damit lassen sich parallel ablaufende Programminstanzen generieren, die nichts voneinander wissen, die damit nicht synchronisiert oder gelockt werden müssen. Das erlaubt eine sichere Implementierung der parallelisierten Anwendung.

Der Concurrency Runtime Scheduler ist ein Dieb: Tasks werden auf die Worker Threads verteilt und parallel ausgeführt. Sobald einer der Worker Threads nichts zu tun hat, “stiehlt” er eine laufende Aufgabe eines anderen Worker Threads, was zu einer besseren Auslastung der vorhandenen Prozessorkerne führt.

Jetzt ist das Aufspüren möglicher Fehler an der Reihe, die sich beim Parallelisieren von Anwendungen ergeben können. Das Beispiel, das Steve hierfür verwendet, ist eine Matrizenmultiplikation. Also nichts Spektakuläres. Hierfür steht in Visual Studio 2010 eine Art Thread Checker parat, der eine Anwendung analysiert und das Ergebnis grafisch aufbereitet. Dazu gehört die CPU-, Core- und Threads-Auslastung.

Die Session beginnt mit einer Folie, die all das zeigt, was Intel in Sachen High Performance Computing tut.

Folie 2 beschäftigt sich mit der Frage, welche Dinge zu berücksichtigen sind, um das Optimum aus seiner Anwendung zu holen. Dazu gehören die Wahl der richtigen Algorithmen, der passenden Programmiersprache und Compiler und natürlich die Frage nach den passenden Software-Tools, mit denen sich Anwendungen optimieren lassen.

Mit Fragen der Portabilität und der Produktivität sollten sich Entwickler ebenfalls beschäftigen. Auch hier geht es um Dinge wie Programmiersprachen, Tools, Betriebssysteme etc.

Jetzt dreht es sich um das Thema Skalierung und was getan werden muss, um eine Beschleunigung der Anwendungen zu erhalten, die sich an der Zahl der vorhandenen Prozessorkerne und Hardware-Threads orientiert.

Ok, jetzt wird’s interessanter. Der Intel-Kollege spricht über die vorhandenen Entwickler-Tools, die Intel bereit hält. Natürlich ist die Rede von Parallel Studio für C/C++-Entwickler, aber auch von Workstation-/Server- und HPC-Tools wie VTune Performance Analyzer, Intel TBB und mehr.

Wer übrigens glaubt, dass Intel sich nur der Windows-Welt verpflichtet fühlt, der irrt. Der Chiphersteller bietet ebenso Software-Tools für die Linux- und Mac-Entwickler dieser Welt.

Eine sehr schöne Folie: die Unterschiede zwischen Task- und datenbasierter Parallelprogrammierung.

Natürlich darf Parallel Studio nicht fehlen. Es geht also um Parallel Advisor, Parallel Composer, Parallel Inspector und Parallel Amplifier.

Vier Schritte, um eine serielle programmierte Anwendung zu parallelisieren:

1. Der Wechsel zum Intel Compiler verbessert ohne direkten Eingriff in den Code die Laufzeit der Anwendung.

2. Die Vektorisierung des Sourcecodes mithilfe von SIMD-Befehlen.

3. Die Implementierung von Intel-MKL-Code.

4. Automatische Parallelisierung mithilfe von OpenMP und andere Techniken.

Ein wenig Zukunftsaussichten gehören natürlich auch dazu: Intel wird seine Tools weiterentwickeln und damit sicher stellen, dass zukünftige Plattformen mit zukünftigen Anwendungen weiterhin skalieren. Dazu gehören unter anderem Weiterentwicklungen basierend auf Cilk++ und Ct.

Am Schluss gibt es noch ein paar Surftipps: Intel Software Network und whatif sollten Parallelprogrammierer auf jeden Fall kennen. Und natürlich das Software Dev Blog. Aber das stand leider nicht auf der Folie …

Neben all den bereits erwähnten Sessions und Keynotes wird es für angehende Parallelprogrammierer ein ganz spezielles Bonbon geben: Am Mittwoch, den 23. September, veranstaltet Intel von 14:00 bis 18:00 Uhr PDT (23:00 bis 24/9, 3:00 Uhr MESZ) einen vierstündigen Workshop, in dem erfahrene C- und C++-Programmierer lernen werden, wie sie mithilfe von Parallel Studio sequenziell programmierten Quellcode parallelisieren können. Als besonderen Anreiz haben sich die Organisatoren dieses Workshops zwei Leckerbissen überlegt:

1. Die ersten 50 Teilnehmer, die ein lauffähiges, parallelisiertes Programm einschicken, erhalten eine Vollversion von Parallel Studio. Gegenwert: 799 Dollar.

2. In drei Kategorien wird der jeweils beste Beitrag ermittelt. Hierbei geht es um die schnellste Ausführung, die beste Prozessorausnutzung und den besten Einsatz von Parallel Studio. Der Sieger (oder die Siegerin) erhalten eine Visa-Geschenkkarte im Wert von 250 Dollar.

Wer schon mal gucken will, was zu tun ist, um eines der 50 Parallel-Studio-Pakete abzugreifen oder gar die 250 Dollar zu gewinnen, kann sich auf der Contest-Seite ausführlich darüber informieren. Und im Evaluation Center von Intel könnt ihr euch eine 30-Tage-Version von Parallel Studio besorgen. Zum Aufwärmen, quasi.

Ach ja: Am zweiten Tag des IDF beginnen die Techsessions erst um 13:05 Uhr PDT (22:05 MESZ), da vormittags zwei Keynote-Sessions anstehen und die Organisatoren obendrein die anwesenden Entwickler dazu ermutigen wollen, den Ausstellerbereich (Technology Showcase) zu besuchen.

13:05 Uhr PDT (22:05 MESZ): Parallel-Guru und Product Unit Manager Steve Teixeira wird 50 Minuten lang über das geplante .NET-4-Framework mit all seinen Vorzügen für Parallelprogrammierer reden. Dabei geht es unter anderem um die Parallel Extensions und das task-basierte Debuggen mithilfe von Visual Studio 2010. Und ein kurzes Produkt-Update gibt es bestimmt auch.

13:05 Uhr PDT (22:05 MESZ): Wer die Intel Threading Building Blocks mal in Aktion sehen will, sollte in den Raum 2000 kommen, um dem Workshop von Victoria Gromova beizuwohnen. Und allen, die den Termin nicht schaffen, empfehle ich die ein oder andere Lektüre.

14:05 Uhr PDT (23:05 MESZ): Eine Techsession mit dem Titel “Next Generation Core-to-Core Interconnects for Many-Core Processors” sollte man eher nicht versäumen. In dem Workshop geht es unter anderem um die Themen Latency, Bandbreite und Traffic Management bei Prozessorverbünden. Aber auch um die möglichen Ansätze, solche Hochgeschwindigkeits-Netze aufzubauen.

14:05 Uhr PDT (23:05 MESZ): Ich sag mal: Qual der Wahl, denn zeitgleich zu der Many-Core-Session gibt es im Raum 3016 interessante Einsichten in das Innenleben von Moorestown, der zukünftigen MID-, Smartphone- und Netbook-Plattform von Intel. Hier erfährt man alles über SOC (System-on-a-chip) im 45-nm-Fertigungsverfahren, verbessertes Energiemanagement inklusive verlängerter Batterielaufzeiten und weitere interessante Details.

15:05 Uhr PDT (24/9, 00:05 MESZ): Im April dieses Jahres habe ich bereits über das Ct-Projekt berichtet, das noch in diesem Jahr in seine Beta-Phase überführt werden soll. Hinter dem Begriff Ct verbirgt sich eine Weiterentwicklung von C++, und zwar für datenbasierte Anwendungen, die beispielsweise bei der Bildbearbeitung oder dem Videoschnitt zum Einsatz kommen. Und genau darüber werden vier Intel-Experten 50 Minuten lang reden: Wie Ct Entwicklern dabei hilft, skalierende Anwendungen zu entwerfen und zu programmieren. Dabei gibt es auch diverse Beispiele zu begutachten.

16:05 Uhr PDT (24/9, 1:05 MESZ): Um kurz nach vier kommen wieder alle Mobil-Geeks auf ihre Kosten: In einer 50-minütigen Techsession gibt es einen Rundumschlag in Sachen Moblin, der Linux-Distribution für mobile Endgeräte. Die anwesenden Entwickler erfahren also, warum Netbooks und andere Gadgets auf Moblin-Basis so schnell booten, was die Hauptbestandteile des Moblin-Kerns sind und was es mit den Fachbegriffen Clutter, GeoClue und ConnMan auf sich hat.

16:05 Uhr PDT (24/9, 1:05 MESZ): Darüber berichtet habe ich ja schon, in Aktion gesehen habe ich ihn allerdings noch nicht: Parallel Advisor, der künftig fester Bestandteil von Parallel Studio werden soll. Daher heißt er auch noch Parallel Advisor Lite und ist in der Lage, diejenige Abschnitte im C++-Code zu finden, die sich besonders für das Multithreaden eignen. Der Advisor trägt aber auch dazu bei, strukturierter zu programmieren und damit weniger fehleranfälligen Sourcecode zu generieren.

17:15 Uhr PDT (24/9, 2:15 MESZ): Moblin überall, so könnte man das diesjährige IDF fast bezeichnen. Daher gibt es um Viertel nach fünf lokaler Zeitrechnung einen guten Überblick, wie sich Anwendungen für das Linux-Derivat programmieren lassen. Robert Bradfort und Bob Spencer werden hierfür Einblicke gewähren in das Moblin SDK, in die APIs, wie sich Web-Apps programmieren lassen und welche Tools sonst nocht bei der Erstellung Moblin-basierter Programme helfen.

Nun ist es aber so, dass ich von 21. bis 27. September in San Francisco weilen werde, um mich ebenfalls an drei Tagen auf dem Intel Developer Forum über die neuesten Entwicklungen aus dem Hause Intel in Sachen Programmierung und mehr zu informieren. Und da ich leider nicht an zwei Orten gleichzeitig sein kann, habe ich mir schon mal den Workshop-Plan ein wenig genauer angesehen. Darüber hinaus habe ich weitere Infos bei der Veranstalterin der Basta angefragt. Hoffentlich bekomme ich etwas zugeschickt. Damit ich es mit euch teilen kann.

Bis dahin lohnt sich auf jeden Fall ein kurzer Blick in die geplanten Inhalte des Power-Workshops von Jeffrey:

Der Titel des Ganzen lautet “Mastering .NET and Preparing for the Multi-Core Revolution”, findet von Montag bis Mittwoch von jeweils 9 bis 18 Uhr im Hotel Contel Mainz statt und kostet regulär 1.550 Euro. Falls sich drei Kollegen aus demselben Unternehmen anmelden, kommt der Workshop 100 Euro günstiger. Und für alle, die sich noch heute anmelden, gibt’s ein Netbook mit sämtlichen Ausgaben des dot.NET Magazins obendrauf.

Für das Geld bekommt man eine ganze Menge: Freien Eintritt zu Basta,  Rundum-Verpflegung und ein Zertifikat der Entwickler-Akademie – und obendrein macht ihr euch fit für das Multicore-Zeitalter. Dabei geht es um folgende Inhalte:

• So gehe ich richtig mit Programmierfehlern mithilfe der Ausnahmebehandlung (exception handling) um.

• So implementiert der C#-Compiler anonyme Methoden und Lambda-Funktionen.

• So ermöglicht und unterstützt C# die funktionale Programmierung.

• Sinn und Bedeutung von Threads und wie sich diese positiv auf die Leistungsfähigkeit einer Anwendung auswirken.

• So vereinfacht der CLR-Threadpool die Programmierung von C#-Anwendungen und beschleunigt diese.

• So führt Windows synchrone und asynchrone I/O-Operationen aus – wie .NET-Entwickler dies zu ihren Gunsten ausnutzen können.

• So teste ich ein parallel programmiertes C#-Programm mithilfe von .NET-Bordmitteln.

Diese und viele weitere Aspekte der Parallelprogrammierung werden also im Detail besprochen. Und, ist das nix?!

Die erste Aufgabe beschäftigt sich übrigens mit der Matrizen-Multiplikation, und zwar auf Basis des Strassen-Algorithmus. Hierfür muss ein kleines parallelisiertes Programm geschrieben werden, das auf einer vorgegebenen seriellen Lösung des Problemes basiert. Mithilfe des Strassen-Algorithmus ist also die parallele Version der seriellen Anwendung zu programmieren. Dabei müssen bestimmte Dinge wie Rumpf der Hauptfunktion erhalten bleiben, andere Dinge wie das Reservieren von notwendigem Speicher dürfen (und müssen) angepasst werden.

Zur Berurteilung der Güte der eingereichten Lösung wird übrigens die Zeit herangezogen, die das kleine Programm für die Matrizenmultiplikation benötgit. Da heißt es also sich anstrengen, um eine möglichst kurze Laufzeit herauszubekommen. Mehr Infos dazu bekommt man auf der Wettbewerbsseite. Viel Spaß und Glück beim Programmieren!

Ach ja: Die Intel Threading Building Blocks könnten beim Lösen der Aufgabe helfen. Nur so als kleiner Tipp …

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

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

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

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

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

Hallo,

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

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

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

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

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

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

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

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

Sodala, die Game Developers Conference 2009 ist Geschichte und wir präsentieren nochmals die schönsten Bilder der Entwicklerkonferenz. Ob CryEngine 3 samt Interview mit Cevat Yerli, Techsessions zu CPU-Fragen, Larrabee, Parallel Studio, Intel Graphics Performance Analyzer oder Duale Zahlen – wir hatte unseren Spaß und haben eine ganze Menge gelernt.

Und die Entwickler hatten auch etwas davon – na, mal vor allem die, die eines der vier Netbooks gewonnen haben. Alle anderen hoffentlich auch. Also, wir sehen uns (wieder) im nächsten Jahr. Gleiche Stelle, gleich Welle. Tschö und macht et jut!

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

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

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

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

Damit wir hier nix Falsches erzählen, konnten wir Gino van den Bergen zu einem Interview überreden, damit er uns etwas über Duale Zahlen erzählt: Worum es in seinem Vortrag ging, warum Spieleentwickler auf Duale Zahlen setzen sollten und was das Ganze mit Larrabee zu tun hat.

Nur soviel: Es geht um “Clean Code”, um die Vereinfachung der Differentialrechnung, und andere schöne Dinge, mit denen vor allem Spieleprogrammierer zu tun haben.

Und jetzt: Film ab!

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!

Und das auf einer Vielzahl von Prozessorkernen, die sowohl für allgemeine Aufgaben taugen als auch für grafisch orientierte (wie viele Cores Larrabee verpasst bekommt, verrät Intel leider noch nicht). Die Schlussfolgerung daraus: Der Befehlssatz von Larrabee (LRBni genannt) wird hoch komplexe mathematische Aufgaben blitzschnell und sehr parallel berechnen.

Steve hat übrigens während seines heutigen Vortrags für besonders schlaue Fragen Mauspads verschenkt, was ziemlich gut ankam (können sich Software-Entwickler die kleinen Matten nicht leisten?!). Außerdem hat er ein wirklich interessantes Statement abgegeben:

Wenn Intel eine Software-Firma wäre, würden wir zu der größten ihrer Zunft gehören!

Soll heißen: Intel beschäftigt mehrere tausend Software-Entwickler, die Jahr für Jahr neue Software-Tools programmieren und bestehende weiterentwickeln. Damit andere Software-Programmierer die Intel-Prozessoren bestmöglich ausschöpfen können. Ganz in Steves Sinne!

Ach ja: Nach seiner zweiten Session hat sich Mister McCalla noch ein wenig Zeit genommen, um unsere Fragen zu beantworten. Wir wollten noch unbedingt wissen, warum sich Game-Programmierer auf Larrabee freuen sollten.

Erst einmal ging es aber um das Tic-Toc-Modell von Intel: Seit 2005 gibt es in den ungeraden Jahren eine neue Prozessorgeneration, in den geraden eine Verkleinerung derselben, da die Fertigungsprozesse ständig verbessert werden. Derzeit steht der grundlegende Wechsel von 45 zu 32 Nanometern an.

Natürlich kam in Leighs Session auch der berühmte Satz “The free lunch is over” zum Einsatz (der zwar ein wenig überstrapaziert ist, aber immer noch Gültigkeit hat). Diese von Herb Sutter geprägte Aussage bezieht sich auf die Tatsache, das seit 2005 die Taktraten nur noch unwesentlich ansteigen (dafür aber die Zahl der Prozessorkerne). Das bedeutet vor allem für Software-Entwickler, dass sie in die Programmierung neuer (oder bestehender) Anwendungen mehr Hirnschmalz stecken müssen, da sie nur noch mit Multithreading und solchen Vorgängen ihre Apps schneller machen können.

Daher lautete Tipp #1 von Leigh an die anwesende Entwicklerschar: “Beschäftigt euch so früh wie möglich mit künftigen Prozessoren!” Nur dann schaffen die Entwickler es nämlich, das Optimum aus der Hardware herauszuholen und damit die eigene Anwendung leistungsfähiger zu machen.

Dazu gehört zum Beispiel die verfügbare Anzahl von Prozessorkerne und möglichen Threads pro Core, aber auch die Evolution der registernahen SIMD-Befehle, die derzeit in der Version 4.2 auf dem Core i7 implementiert sind. Aus diesem Grund lautet Tipp #2: “Eure Kunden haben SSE, also nutzt es!”

Abschließend folgte Leighs Tipp #3, und der hat mit der Bestimmung der vorhandenen Prozessorkerne in einem PC zu tun: “Das ‘Erraten’ von CPU-Kernen ist ziemlich gefährlich, also gebt euch Mühe, diese zu berechnen!” Hierfür gibt es übrigens detaillierte Codebespiele auf intel.com.

Ja, und anschließend stand uns Leigh Davies noch für drei schlaue Fragen samt schlauer Antworten parat. Daher: Film ab!

Ansonsten war die Keynote-Präsentation wenig spektakulär, bot aber trotzdem interessante Einblicke in die Evolution der CryEngine. Diese erblickte in Form des Spieletitels Far Cry quasi das Licht der Welt (das Spiel selbst wurde zwischen 2001 und 2004 entwickelt). Mit Far Cry waren zum ersten Mal Pixel Shading, Bumpmapping, Vertex Shading und HDR möglich – ein echter Meilenstein im 3D-Gaming also.

Im November 2007 folgte dann Crysis, das auf der Folgegeneration CryEngine 2 basiert. Damit sah sich selbst Crytek auf einem guten Weg in Sachen fotorealistisches Rendering. Ein wesentlicher Unterschied zur Vorgänger-Engine war die verbesserte Skalierbarkeit von CryEngine 2, sowohl bei den 3D-Daten als auch bei der Pipeline.

Tja, und nun gibt es bereits CryEngine 3, die sich allerdings noch im Betastadium befindet. Die neuen Möglichkeiten sind allerdings jetzt schon sehr beeindruckend: Neben skalierendem Many-/Multicore-Support bietet CryEngine 3 weitreichende grafische Verbesserungen. Aber auch die Entwicklungsumgebung hat es in sich: Wie man sich am Crytek-Stand im Ausstellerbereich überzeugen kann, erlaubt das Entwicklersystem die parallele Kreation eines Spielelevels für PC, Xbox und PlayStation zur selben Zeit. Das ermöglicht ein sehr effizientes simultanes Testen eines neuen Levels. Dazu werden wir noch Bewegtbilder nachreichen.

Aber natürlich wagte Cevat auch einen Blick in seine Kristallkugel, was in Sachen 3D-Spiele auf uns zukommt: Dazu gehörte die Feststellung, dass künftige Grafikprozessoren immer leistungsfähiger, da paralleler werden und zudem immer mehr Prozessoraufgaben übernehmen werden (hallo, Larrabee). Daneben fand ich die Tatsache halbwegs überraschend, dass es noch bis 2012 dauern wird, bis wir Abschied nehmen werden von festen Auflösungen innerhalb eines Spiels. Daher werden sich Spieleentwickler weiterhin darauf konzentrieren müssen, ihre Designs weiter zu verfeinern, die Physics Engines zu verbessern und die AI zu erhöhen. Nur auf diesem Weg lassen sich Spiele weiterhin differenzieren.

Ach ja: Direkt im Anschluss an seine Keynote stellte sich Cevat Yerli unseren vier Fragen. Die Antworten geben kurz und knapp Auskunft über seine Präsentation, über die Besonderheiten von CryEngine 3, über die Grafikengine der Zukunft und eine kleine Einschätzung in Sachen Larrabee. Danke, Cevat!

• Am Intel-Stand ging’s von der ersten Minute an richtig rund. Soll heißen, die Demos zu Parallel Studio, Intel TBB, Intel GPA und anderen Tools und Techniken sind ein echter Renner. Obendrein zieht das Gewinnspiel, bei dem man ein schickes Asus-Netbook abgreifen kann, die Leute an den Stand. Das liegt natürlich vor allem an “fabulous” Kellie!

• Die Keynote von Cevat Yerli, seines Zeichens CEO von Crytek, war richtig gut besucht. Kein Wunder, es ging schließlich um die Zukunft der Grafik-Engine. Und über die Vergangenheit ebenfalls, mitels CryEngine 1 und 2.

• Das Interview mit Cevat war kurz, knackig und sehr pointiert. Aber dazu gibt es etwas später mehr. So, stay tuned …

Ach ja: Wir haben schon mal ein wenig gedreht und die besten Impressionen in einen 80-Sekünder gepackt. So als Aufwärmprogramm – quasi …

Dazu gehören Keynote-Vorträge von Cevat Yerli, seines Zeichens CEO von Crytek, David Cage von Quantic Dream und anderen wichtigen Köpfen der Spielebranche. Das Bild der Konferenz werden allerdings die zahlreiche Sessions aus den Themenbereichen Geschäftsmodelle, Game Design, Produktionsabläufe, Programmierung und Entwicklung sowie Visual Arts bestimmen.

Das Software Dev Blog interessiert sich natürlich hauptsächlich für die technischen Vorträge. Daher werden wir uns – ausgestattet mit Notebook und Videokamera – auf die Suche machen nach interessanten Gesprächspartnern und spannenden Inhalten. Wir werden also unter anderem mit Leigh Davies darüber reden, worauf es beim Entwickeln von Software ankommt und warum mit jeder neuen Prozessorgeneration neue Herausforderungen und Chancen auf Spieleentwickler zukommen.

Natürlich werden wir uns auch das Entwicklertool Graphics Performance Analyzers ansehen und uns von Steve Hughes zeigen lassen, wie es Sega mithilfe der Toolsuite geschafft hat, ihren Spieletitel “Empire: Total War” für integrierte Grafikchips zu optimieren. Darüber hinaus werden wir uns in die Larrabee-Sessions setzen und mit den zuständigen Intel-Ingenieuren reden, was es mit der Vektorisierung und Rasterisierung sowie dem parallelen Speichern und Laden mithilfe des Befehlssatzes LRBni auf sich hat.

Daneben werden wir natürlich unsere Fühler ausstrecken und die interessantesten Infos auf der GDC09 ausgraben. Sicherlich fündig werden wir am Crytek-Stand im großen Aussteller-Areal. Dort kann man nämlich die CryEngine 3 bewundern. Und hoffentlich können wir mit den Ubisoft-Leuten am Stand 153 über Anno 1404 reden – und über die Bemühungen reden, die in Sachen Multicore-Optimierung in dem Spieltitel stecken.

Deshalb solltet ihr es auf keinen Fall verpassen, von Montag bis Mittwoch unsere Liveberichterstattung von der GDC09 mitzuverfolgen. Und zwar per Blog, Videoclips und Twitter. Die volle Bandbreite eben!

Dieser trägt offiziell den Titel SIMD programming with Larrabee: Second Glance at the New Instructions in Action und beschäftigt sich sehr detailliert mit der SIMD-, also registernahen Programmierung von Larrabee-basierter Software. Hierzu werden Steve Hughes und Steve McCalla von Intel sehr tief in die Materie einsteigen und darüber referieren, dass …

… zu jedem Larrabee-CPU-Kern 32 Vektor-Register gehören, die jeweils 16 Bit breit sind und sich für parallel ausführbare Operationen nutzen lassen. Das ergibt in Summe 512 breite SIMD-Register pro Core.

… die Larrabee-nahe Programmierung zwei Methoden bereithält, um Vektoroperationen durchzuführen: SOA (Structure of Arrays) und AOS (Array of Structure). Beide haben ihre Berechtigung und Steve & Steve werden ausführlich darlegen, in welchem Fall welche der beiden Methoden die bessere ist. Und das anhand einfacher mathematischer Beispiele wie der Matrizenberechnung.

… Predication acht 16-Bit-breite Register nutzt, um vektorbasierte Vergleichsoperation parallel durchzuführen. Damit sind auch klassische x86-Schleifenkonstrukte realisierbar.

… Gather und Scatter ebenfalls ganz wichtig sind, wenn man über Larrabee-Programmierung redet. Gather entspricht einem auf 16 Floatingpoint-Registern parallel ausführbaren Ladebefehl pro Kern. Und Scatter bezeichnet den umgekehrten Weg, also das simultane Speichern dieser 512 Bit breiten Vektoren. Dabei werden wir auch lernen, dass Gather und Scatter wesentlich von der Cache-Taktung abhängig sind.

… es bereits eine C++ Larrabee Protoype-Bibliothek gibt, in der es nur noch einen Header und keine .lib- oder .dll-Dateien mehr gibt. Zudem wird wohl das Debuggen um einiges einfacher sein und es sollen möglichst sämtliche bestehenden Plattformen unterstützt werden.

Es gibt also viele gute Gründe, sich den Dienstagmorgen (10:10 bis 11:00 Uhr MESZ) zu reservieren, um entweder direkt auf der GDC’09 zu Köln die Larrabee-Session live mitzuerleben oder hier auf diesem Blog vorbeizuschauen. Denn wir werden in Bild und Ton darüber berichten, was Steve & Steve zu erzählen haben – und warum man als 3D-Programmierer in Zukunft wohl kaum noch an Larrabee vorbeikommen wird.

Natürlich wird Leigh Davies in seiner Session auch kurz und knapp auf Larrabee eingehen. In diesem Zusammenhang habe ich versprochen, euch ein paar mehr Infos zu den Larrabee-Sessions zukommen zu lassen. Dieses Versprechen löse ich hiermit ein. Ok, eigentlich ist der heutige Beitrag nur die eine Hälfte des eingelösten Versprechens, da die Kurzfassung des zweiten Larrabee-Vortrags morgen folgt.

Nach einer kurzen Einführung, was Larrabee ist und wozu es eingesetzt werden kann, wird Steve McCalla von Intel ziemlich schnell in Medias Res gehen. Ohne Umschweife wird er über einen Teil der mehr als 100 neuen Befehle reden, die Larrabee zu bieten hat. Dazu gehören vor allem Vektor-Befehle, mit deren Hilfe bestimmte Operationen wie Multiplikation und Addition in den vorhandenen 32 Vektor-Registern parallel ausgeführt werden können (diese Register v0 bis v31 sind übrigens allesamt 512 Bit breit!).

Steve wird aber auch darüber referieren, dass notwendige Datenkonvertierungen bereits während eines LOAD-Befehls durchgeführt werden können. Und beim Speichern von Daten ist diese Umwandlung natürlich auch möglich.

Doch was nützt die schönste Theorie, wenn die Praxis nicht zu Wort kommt. Daher steigt Steve in die Larrabee-Programmierung ein und zeigt anhand diverser Bespiele, dass man mit relativ wenig Aufwand die volle Bandbreite von Larrabee effizient nutzen kann. Dazu gehört ein sehr komplexes Mandelbrot-Codebeispiel, aber auch einfache mathematische Operationen sollen die Vorteile der Vektorisierung zeigen. Und so geht es weiter: Steve spricht über Broadcast- und Konvertierungsbeispiele, über die GPU-Eigenschaften von Larrabee und sehr ausführlich über die Rasterisierung mit der neuen GPGPU-Technik von Intel.

Ach ja: Ich bin ja schon sehr gespannt, ob Tim Sweeney von Epic Games zu Wort kommen wird. Der hatte nämlich schon mal die Gelegenheit, einen Blick auf Larrabee zu werfen, und befand kurz und knapp: “Larrabee rocks!” Oder etwas genauer gesagt: “Jede traditionell programmierte Schleife kann vektorisiert und mithilfe der Larrabee-Vektoren parallel ausgeführt werden!” Oder so ähnlich …

Wenn ihr auch wissen wollt, ob Tim das wirklich gesagt hat, solltet ihr es auf keinen Fall versäumen, unsere Liveberichterstattung aus Köln mitzuverfolgen. Ich bin nämlich gemeinsam mit dem Kollegen Papadhimas vor Ort und werde über alles Wissenswerte berichten, was sich auf der GDC Europe 2009 zuträgt. Drei volle Tage. Das rockt!

Am Montag um 17:40 Uhr stellt sich Leigh Davies die Frage, wie Spieleentwickler Schritt halten können mit den permanenten Neuentwicklungen im Prozessorsegment – und was sie davon haben. Es geht also um aktuelle Mikroarchitekturen von Intel (Core 2, Core i7) und geplante Prozessoren (Westmere, Sandy Bridge). Letztere werden übrigens ausschließlich auf 32-nm-Basis gefertigt. An diese ständigen Veränderungen sollten sich die Spieleentwickler permanent anpassen können. Spieleprogrammierer sind vor allem dazu aufgerufen, nicht mehr ausschließlich sequenziell, sondern auch parallel zu entwickeln.

Leigh bleibt aber nicht an der Oberfläche: So wird er die letzten drei Mikroarchitekturen (Pentium 4, Core und Core i7) genauer beleuchten und die Vorteile erläutern, die vor allem die neueren Architekturen mit sich bringen. Und zu der aktuellen Core-i7-Architektur gibt es ganz besonders viele Informationen. Also solche Dinge wie verbesserte Sprungvorhersagen, höhere Speicherbandbreiten und vieles mehr.

Vor allem das verbesserte Speichersystem der Core-i7-Architektur ist für Spieleentwickler eine große Chance: Die Latenzzeiten sind im Vergleich zur Core-Architektur deutlich geringer (zirka minus 40 Prozent) und die Bandbreite konnte drastisch erhöht werden (von zirka 10 GByte/Sek. auf rund 33 GByte/Sek.). Das ist vor allem für hochkomplexe 3D-Gebilde mit vielen tausenden von Polygonen ein echter Glücksfall.

Aber auch von der hardware-nahen Programmierung mithilfe der SSE-Befehlssätze profitieren 3D-Spiele. Dank der SSE4-Befehle können viele Operationen noch schneller und effizienter ausgeführt werden. Darum lautet ein gut gemeinter Rat von Leigh Davies: “Eure Kunden haben SSE-basierte Hardware – also macht auch etwas damit!”

Es geht aber nicht nur um Speicheraspekte, sondern auch um das Hyperthreading, das von vielen Intel-CPUs unterstützt wird (Intel nennt es auch SMT = Simultaneous Multithreading). SMT bietet standardmäßig ein gewisses Maß an eingebauter Parallelität: Es werden zwei Threads gleichzeitig verarbeitet, Ressourcen werden simultan genutzt und aufgrund der optimierten Out-of-Order-Verarbeitung können verbesserte CPI-Werte erreicht werden (CPI = Clockticks per Instruction). Die gute Nachricht: Die Core-i7-Architektur beherrscht SMT noch ein ganzes Stück besser, da die Caches größer sind, die Bandbreite wesentlich erhöht wurde und auch die Execution Units schneller rechnen können.

Natürlich kommt während Leighs Session die Zukunft nicht zu kurz: So wird die die nächste Prozessorgeneration mit dem Codenamen “Sandy Bridge” standardmäßig 256-Bit-breite SSE-Register aufweisen, was die parallele Datenverarbeitung auf Prozessorebene erheblich beschleunigen wird. Klar ist auch, dass Mister Davies über Larrabeee und dessen Auswirkungen auf die Softwareentwicklung referieren wird. Aber hierfür gibt es ja schließlich zwei eigene Techsessions. Hiervon wird auch noch die Rede sein. Versprochen!

Dazu gehören vor allem die Techsessions, die unter Programming aufgeführt sind:

• Bringing ‘Empire: Total War’ to the masses with Intel’s Graphics Performance Analyzers: In dieser Techsession geht es um die Optimierung von 3D-Spielen für integrierte Grafikchips, wie sie immer öfter in Notebooks zu finden sind. Hierfür gibt es übrigens eine Toolsuite, die sich Graphics Performance Analyzers nennt und dafür sorgt, dass 3D-Spiele gut aussehen und trotzdem auf Grafikeinheiten à la Intel GMA X4500 flüssig laufen – und den Akku schonen.

• Dual Numbers: Simple Math, Easy C++ Coding, and Lots of Tricks: Am Ende dieser Session sollen vor allem C++-Programmierer verstehen, wie sie ihre Herausforderungen mithilfe von Dualen Zahlen bei der Programmierung von Grafik- und Physics-Einheiten besser meistern. Duale Zahlen werden insbesondere bei der Berechnung von Matrizen eingesetzt, spielen aber auch in der Geometrie und bei der Differentialrechnung eine wichtige Rolle.

• SIMD programming with Larrabee: First Glance at the New Instructions in Action: In diesem TechTalk geht es um den neuen Befehlssatz LRBni, der für die Programmierung von Larrabee-basierten Plattformen zum Einsatz kommen wird. Steve McCalla von Intel wird dabei mit einfachen mathematischen Beispielen beginnen, weiter machen mit Schleifenkonstrukten und komplexen Flusskontrollen und letztlich bei der Frage landen, wie sich diese Algorithmen mithilfe von LRBni implementieren lassen.

• SIMD programming with Larrabee: Second Glance at the New Instructions in Action: Wenn es von Steve einen ersten Blick auf LRBni gibt, darf ein zweiter natürlich nicht fehlen. In dieser Session werden Steve (Hughes) & Steve (McCalla) ein wenig mehr über den Befehlssatz erzählen, den LRBni zu bieten hat. Es geht also um sehr breite SIMD-Register, spezielle Multiplikation-Addition-Befehle, eingebaute Datenkonvertierung und einiges mehr.

• Who Moved the Goalposts? The Rapidly changing World of CPU’s and Optimization: Wer kann da noch Schritt halten: Core 2 Quad, Core 2 Extreme, Core i7, demnächst Core i5 und, und, und. Intel bringt scheinbar permanent neue Prozessoren auf den Markt, und alle bieten neue Features und neue Möglichkeiten für Spieleentwickler. Um das CPU-Gestrüpp ein wenig zu entwirren, stellt Intel-Mann Leigh Davies die aktuellen (und künftigen?) Prozessoren vor und nennt deren Wesensmerkmale und wie sich Programmierer diese zu eigen machen können. Für noch bessere und schnellere Computerspiele.

Bevor ich’s vergesse: Ich werde während der drei Tage GDC09 in Köln nicht nur livebloggen, sondern kann zudem die Videodienste von Tom Papadhimas in Anspruch nehmen. Es gibt also auch bewegte Bilder, in denen wir die Größen der Spiele-Industrie mit Fragen löchern werden. Darauf freuen wir uns schon sehr – und ihr euch hoffentlich auch.

• Montagmorgen, 9 Uhr, geht es los mit den ersten Sessions, die bis 18:3o angeboten werden. Von 10 bis 18 Uhr kann man sich aber auch in entspannter Atmosphäre mit den Ausstellern über deren Produkte unterhalten. Dies gilt auch für den Dienstag; am Mittwoch enden die Sessions allerdings schon um kurz nach 16:00 Uhr.

• Am Montag um 11:20 Uhr wird es dann zum ersten Mal richtig interessant: Da hält Crytek-Chef Cevat Yerli seine Keynote unter dem Titel “The Future of Gaming Graphics”. Dabei geht es natürlich auch um die CryEngine 2, aber auch um das Rendern hochkomplexer 3D-Gebilde.

• Am Dienstag sollte man auf keinen Fall die Keynote von David Cage verpassen. David ist CEO von Quantic Dream und ist unter anderem verantwortlich für den Titel Indigo Prophecy. Der Titel seines Vortrags: “Writing Interactive Narrative for a Mature Audience”. Ob er uns dabei einen Blick hinter die Kulissen in Sachen Heavy Rain gewährt, kann man nur hoffen.

• Das absolute Highlight am Mittwochvormittag ist sicherlich die Keynote von Klass Kersting von Gameforge. In seinem Vortrag geht es wohl um Geschäftsmodelle, zumindest lässt das der Titel vermuten: “Changes in the Games Industry – Free-to-play vs. Payment Models”.

Neben diesen interessanten Keynotes wird es eine Reihe sogenannter Techsessions geben, in denen der geneigte Zuhörer sehr kompakt und sehr fundiert über neue Techniken und Entwicklungen der Spieleprogrammierung informiert wird. Welche ich mir auf jeden Fall selbst geben werde, erfahrt ihr in meinem morgigen GDC09-Blogpost.

Ach ja: Natürlich werde ich mir die Sessions nicht nur anhören, sondern auch live und in Farbe darüber berichten. Zu diesem Zweck fährt Tom Papadhimas mit nach Köln und hat seine Videokamera dabei. Es gibt also nicht nur das geschriebene Wort, sondern auch bewegte Bilder, in denen wir die Größen der Spiele-Industrie mit Fragen malträtieren werden. Darauf freuen wir uns schon sehr – und ihr euch hoffentlich auch.

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

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

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

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

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

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

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

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

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

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

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