Sämtliche Beiträge des Monats Juni 2010
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.
Lesetipp: Netbook-Apps unter MeeGo parallelisieren
Den besonders aufmerksamen Lesern des Software Dev Blog dürfte der Name Edmund Preiss nicht unbekannt sein. Edmund liefert immer wieder Beiträge rund um das Thema Parallelisierung für die Fachzeitschrift Elektronik Industrie, die dankenswerterweise sowohl offline als auch online verfügbar sind.
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.
Tech-Ed 2010: Jetzt anmelden und 500 Euro sparen
Anfang Mai habe ich schon darüber gebloggt: die Microsoft Tech-Ed Europe findet auch in diesem Jahr wieder in Berlin statt, und zwar vom 8. bis 12. November. Ich hoffe ja, dass ihr alle den Termin schon mal im Kalender vorgemerkt habt. Und ab sofort solltet ihr euch nicht nur darauf freuen, sondern euch auch für die Microsoft-Konferenz anmelden. Und wenn ihr ganz besonders schnell seid, könnt ihr satte 500 Euro sparen. Dieses “Early-Bird”-Angebot gilt genau bis zum 5. Juli und reduziert den All-Inclusive-Pass von 1.895 Euro auf 1.395 Euro.
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.
Fünf Tipps für das Parallelisieren von Anwendungen
Gerade habe ich bei den Kollegen des SoftTalk-Blogs eine interessante Top-10-Liste gefunden. Die geht der Frage nach, wie aus seriell programmierten Apps parallel ablaufende Anwendungen werden, die im Zeitalter von Multicore-Systemen möglichst gut skalieren und sämtliche vorhandenen Prozessorkerne für die Ausführung der Software optimal nutzen. Daher folgen jetzt meine fünf Lieblingstipps mit entsprechenden Kommentaren und Verweisen.
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.
dotnet Cologne 2010 #3: Noch mehr Infos und Präsentationen
Ja doch, ich geb’s ja zu, ich bin mit meinem dritten Teil der dotnet Cologne 2010 (Teil 1 und Teil 2) ein wenig in Verzug. Und da ich dies natürlich wieder gutmachen möchte, gibt es heute neben den Infos zu den zwei noch ausstehenden Sessions von Oliver Sturm und Bernd Marquardt ein Schmankerl (bayerisches Idiom für “Leckerbissen”) dazu: Es sind nämlich schon ganz viele Präsentationen der Techsessions online, die man sich von dort einfach auf seinen Rechner laden kann. Ein toller Service für alle, die nicht dabei sein konnten oder durften oder sonst was.
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.
Parallel programmieren und Preise abgreifen
Nein, es ist nicht die erste Herausforderung für Software-Entwickler, die sich Intel da ausgedacht hat. Der Wettbewerb mit dem generischen Namen Intel Threading Challenge 2010 geht nämlich in die nächste Runde, und dafür hat sich der Chiphersteller etwas ganz Besonderes einfallen lassen. Anstatt nur eine Zielgruppe mit dem Wettbewerb anzusprechen, unterteilt sich die Challenge 2010 in “Anfänger” und “Fortgeschrittene”. Damit können sowohl Newbies der Parallelprogrammierung als auch die alten Hasen zeigen, wieviel sie vom Thema Multithreading und Co. verstehen.
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ß!
dotnet Cologne 2010, ein voller Erfolg – Teil 2
Wie ich bereits berichtete, habe ich mich letzte Woche auf der dotnet Cologne 2010 herumgetrieben und mir dabei die Sessions von Rami Radi, Mario Deilmann, Oliver Sturm und Bernd Marquardt zu Gemüte geführt. Auf die Session von Rami bin ich ja bereits ausführlich eingegangen, und jetzt folgen noch die von Mario, Oliver und Bernd.
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.
