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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Artikelempfehlungen rund um Parallelprogrammierung

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

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

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

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

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

Parallelprogrammieren lernen mit Schach

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

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

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

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

Infos aus erster Hand zu Cilk

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Weitere Erkenntnisse der Jungbluth’schen Techsession:

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

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

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

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

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

Toll an OpenMP sind aber auch andere Aspekte:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

dotnetpro.powerdays: Multicore-Programmierung

Morgen ist es also soweit: Da geht es im Holiday Inn um 9:00 Uhr los, und das übergeordnete Thema heißt “Multicore-Programmierung”. Klar, dass ich auch dort sein werde, um in gewohnter Manier darüber zu berichten – in Form von Tweets und Blogbeiträgen. Es geht dabei um folgende Sessions:

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

Lesetipp: Elektroniknet.de über die “Softwarefirma Intel”

Ok, die jährlich stattfindende Intel-Software-Konferenz iSTEP ist schon wieder eine ganze Weile her, aber nichtsdestotrotz hat es sich Kollege Joachim Kroll von elektroniknet.de nicht nehmen lassen, die Veranstaltung und seine Lehren und Erkenntnisse daraus auf drei Seiten zusammen zu fassen. Es ist ein sehr gelungener Beitrag geworden, dessen Kernaussagen ich ein wenig kommentieren möchte.

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.