Screencasts zur Parallelprogrammierung unter .NET 4

Der Name Dariusz Parys ist regelmäßig wiederkehrenden Besuchern dieses Blogs ein bekannter Name: Entweder stellt er sich unseren Fragen oder veranstaltet gemeinsam mit Intel TechTalks oder nimmt Screencasts auf, die er zum Wohle aller online stellt. Und genau die haben es mir besonders angetan, da man in relativ kurzer Zeit eine Menge über das parallele Programmieren unter .NET 4 mithilfe von Visual Studio 2010 lernen kann.

Daher hat’s mich sehr gefreut, dass ich heute Morgen zwei “neue” Screencasts” auf Channel 9 gefunden habe. Das erste beschäftigte sich mit der Frage, wie sich die Klasse Parallel dazu nutzen lässt, mehrere Funktionsblöcke gleichzeitig auf mehreren Prozessorkernen ablaufen zu lassen. Hierzu stellt die Parallel-Klasse ein Methode zur Verfügung, die sich Invoke nennt.

Praktisch an dieser Form der Parallelisierung ist die Tatsache, das die gleichzeitig ablaufenden Funktionen nicht synchronisiert werden müssen. Der Mainthread wird nämlich erst dann fortgesetzt, wenn die parallelen Threads fertig sind. Darum kümmert sich die Concurrency Runtime.

Screencast Nummer 2 zeigt in nur sechs Minuten, wie sich Tasks definieren lassen, die einen Rückgabewert liefern. Auch das hat den großen Vorteil, dass der Mainthread nicht unnötig warten muss, bis ein oder mehrere parallel ablaufende Aufgaben fertig sind. Die Übergabe des Returnwertes sorgt nämlich für die Synchronisation des Programmablaufs. Schön daran ist zudem, dass sich auf diesem Weg mehrere Tasks verknüpfen lassen und so ein Folgetask mit dem Rückgabewert des Vorgängertasks “gefüttert” werden kann. Es lassen sich aber nicht nur einfache Werte, sondern auch Objekte übergeben.

Warum Demigod auch auf Notebooks spielbar ist

Was ist der Traum aller Spiele-Publisher? Genau, dass ihre Spieletitel auf möglichst vielen Plattformen laufen. Daher sind sie stets in Sorge, dass ihre Games nicht nur auf einem Highend-PC gut aussehen, sondern auch auf einem Notebook mit integriertem Grafikchip, ohne dabei zu viele Kompromisse in Sachen 3D-Opulenz hinnehmen zu müssen. Klar ist aber, dass es vor allem um ein ausgewogenes Verhältnis von Spielbarkeit und realistischen Effekten geht.

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

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

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

Videosessions: TechTalks mit Intel und Microsoft

Der Juni 2009 stand bei Intel und Microsoft ganz im Zeichen der parallelen Programmierung (woran sich im Juli natürlich nichts geändert hat). Daher fanden zu diversen Terminen in diversen Städten sogenannte TechTalks statt, die erfahrungsgemäß immer sehr gut besucht sind.

Ich war auf der Veranstaltung in München und konnte mich selbst davon überzeugen: der Raum war proppenvoll, da das Thema wohl für viele sehr spannend ist. Der Bedarf nach mehr Wissen zum Thema Parallelprogrammierung ist sehr groß, und mindestens genauso groß sind die Lücken, die sich dazu bei vielen Entwicklern auftun.

Nun, diese Defizite konnten Intel und Microsoft hoffentlich ein wenig beheben. Und wer selbst nicht die Gelegenheit hatte, sich vor Ort ein eigenes Bild davon zu machen, was es mit der parallelen Programmierung auf sich hat, dem seien die drei Videoclips empfohlen, die Microsoft online gestellt hat.

Allerdings sollte man sich viel Zeit nehmen, denn die Videokollektion umfasst mehr als drei Stunden Anschauungsmaterial zu diversen Themen:

• Warum wird Parallel Computing immer wichtiger?

• Was genau verbirgt sich hinter Parallel Studio?

• Was kommt alles auf Entwickler mit Visual Studio 2010 und .NET 4 zu?

• Wer braucht Intel Threading Building Blocks?

Deshalb: Popcorn und Coke bereitstellen, Füße hochlegen und Videos gucken. Und zwar welche der lehrreichen Sorte, Powerpoint-Folien inklusive.

Colin McRae DiRT 2 unterstützt DirectX 11 und Multithreading

So weit ich mich noch erinnern kann, war Colin McRae eines der allerersten Rennspiele, das ich ausgiebig auf dem PC  “getestet” habe. Und es sah damals schon verdammt gut aus und ließ sich auch ganz passabel steuern.

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

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

Warum “Empire: Total War” auf Notebooks so gut läuft

Die Geburtsstunde dieses Blogs hat mit der Entwicklerkonferenz GCDC 2008 zu tun, auf der ich mich gemeinsam mit dem Kollegen Papadhimas tummelte und wichtigen Köpfen der Spiele-Industrie wichtige Fragen gestellt habe. Das war vergangenes Jahr in Leipzig.

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

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

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

Paralleltesten mit Visual Studio: Parallel Debugger Extension

Klar, Microsofts Visual Studio bietet eine erprobte Debugging-Umgebung, mit der sich Anwendungen auf mögliche Fehler untersuchen lassen. Allerdings gilt dies nur für sequentiell programmierte Software, potenziellen Multithread-Problemen kommt man mit diesem Tool nicht auf die Schliche. Hierfür bietet sich ein Tool an, das Teil des Parallel Studio ist und sich Parallel Composer nennt. Teil des Composers wiederum ist die Parallel Debugger Extension, die sich als Erweiterung in die Debugger-Umgebung von Visual Studio “einklinkt”.

Die Parallel Debugger Extension weist folgende Hauptmerkmale auf:

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

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

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

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

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

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

Vergleich: Intel Thread Checker versus Parallel Inspector

Auf dem Intel Software Network habe ich eine interessante Gegenüberstellung gefunden, die auf einen Blick zeigt, worin sich die Tools Intel Thread Checker und Intel Parallel Inspector unterscheiden. Daraus ergeben sich interessante Aspekte:

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

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

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

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

Linux-Debugger für C++ und Fortran mit grafischer Oberfläche

Es soll ja Leute geben, die (a) nicht viel von grafisch basierten Oberflächen halten und (b) nicht wissen, dass die Intel-Linux-Compiler für C/C++ und Fortran einen solchen GUI-Debugger mitbringen. Dieselben konnte ich mir vorletzte Woche während meines Besuchs bei Intel in Ulm ansehen und mir ein Bild von ihren Fähigkeiten machen. Und das kam dabei heraus (mehr dazu folgt noch diese Woche mit weiteren Details und ein paar interessanten Bildern).

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

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

weiterlesen…

EXASolution ermöglicht Datenanalysen in Quasi-Echtzeit

Über Exasol habe ich in der Vergangenheit ja schon berichtet. Letzte Woche dann wurde aus der Theorie Praxis, und zwar in Form einer Roadshow, auf der Anwender zu Wort und eine kurze Demo zum Einsatz kamen.

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

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

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

weiterlesen…

Intel Ulm und die Linux-Debugger-Tools

Vorige Woche war ich auf Reisen. Die Destination meiner Unternehmung: Die württembergische Außenstelle der Firma Intel, die sich in Ulm befindet. Um es kurz zu machen: Sehr beeindruckend, was ich dort alles gesehen und gelernt habe. Zunächst einmal muss ich aber ein paar Dinge klarstellen, über die ich im Vorfeld berichtet hatte:

1. Der Windows-C++-Compiler für Windows CE wird in Ulm nicht mehr entwickelt und spielt seit dem Erscheinen des Atom-Prozessors auch keine große Rolle mehr. Denn selbst Embedded-Systeme setzen immer öfter auf die Netbook-CPU und ermöglichen damit den Einsatz standardisierter Betriebssysteme wie Linux und Windows mit den zugehörigen Entwicklertools.

2. Die Software-Werkzeuge, um die es bei Intel in Ulm vor allem geht, helfen Programmierern und Entwicklern, ihre Anwendungen fehlerfrei unters Volk zu bringen. Hierfür konzentrieren sich die Ulmer Kollegen auf die Debugger-Tools, die sowohl unter Windows als auch unter Linux zum Einsatz kommen. Interessant an meinem Besuch war unter anderem die Erkenntnis, dass die Parallel Debugger Extension, die sowohl im Parallel Studio als auch in der aktuellen Version des Intel-C++-Compilers stecken, “made in Ulm” sind. Na ja, auf jeden Fall zu einem großen Teil.

3. Das Intel-Büro in Ulm ist entgegen meinen ersten Erwartungen alles andere als beschaulich. Es befindet sich in einem architektonisch höchst interessanten Gebäude, das sogar über einen eigenen Teich verfügt. Auf zwei Stockwerken arbeiten 30 bis 40 Leute vorwiegend an den neuesten Debugger-Tools – auf dass künftige Software möglichst fehlerfrei läuft. Aber auch diverse Entwicklertools für den Atom-Prozessor werden in Ulm konzipiert und entwickelt.

weiterlesen…

Intel Ulm versorgt den Embedded-Markt mit Tools

Dass Intel seinen Hauptsitz D in Feldkirchen bei München hat, dürften ein paar Leute wissen. Dass es aber darüber hinaus weitere Büros gibt, in denen Spezialanwendungen entwickelt und gepflegt werden, ist wohl nicht wirklich bekannt. Da wäre zum Beispiel Niederlassung in Brühl bei Köln, wo Software-Tools für HPC-Anwendungen entwickelt und programmiert werden. Oder Braunschweig: Dort erschafft man neue Mikroprozessoren, und das Microprocessor Lab Germany ist sogar an der Entwicklung des Projekts Tera Scale Computing beteiligt.

Ach ja, und dann wäre noch Ulm zu nennen. In diesem eher beschaulichen Büro wurde und wird der C++-Compiler für Windows CE entwickelt. Dieses Betriebssystem kommt in Embedded Systemen zum Einsatz. Natürlich geht es in Ulm auch um die passenden Debugger und Simulationsprogramme, mit denen sich hochspezialisierte Anwendungen ausführlich testen lassen.

Und warum erzähle ich das alles? Nun, ich sitze hier gerade im ICE 690 gen Berlin und werde voraussichtlich 9:49 in Ulm aussteigen, um das Intel-Büro und all seine Tools und Projekte ein wenig genauer zu inspizieren. Dabei werde ich bestimmt ein Menge über Embedded-Compiler und -Anwendungen lernen und erfahren und darüber, was den Standort Ulm so einzigartig macht. Abgesehen von Donau, Ulmer Münster und Co. Und klar, dass ich das alles hier publizieren werde. So, stay tuned …