Multicore-Workshop mit Jeffrey Richter parallel zur Basta
Von 21. bis 25. September findet in Mainz die Basta! 2009 statt, eine der größten unabhängigen Entwicklerkonferenzen in diesem Land. Gerne würde ich ja dort hinfahren, um mir die eine oder andere Session anzuhören und darüber zu bloggen. Besonders interessant finde ich natürlich den Multicore-Workshop von Jeffrey Richter, der parallel zur Basta an drei Tagen stattfindet.
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.
Zurück zum Multicore-Blogging: Post-Konferenzing
Die vorige Woche stand ganz im Zeichen der Multicore-Konferenzen. Los ging’s am Montagabend in Salzburg bei Bier und Brez’n im Pitterkeller des ehrwürdigen Crown Plaza, wo ich mit netten Kollegen zusammensaß und über dies und das geplaudert habe. Das Dienstagsprogramm rankte sich dann um das Thema Multicore-Programmierung und Parallel Studio, aber auch um andere Dinge wie das Nero-Engagement und Microsoft-Bemühungen.
Mittwoch ging es dann wieder nach München, damit ich am Donnerstag auch ja pünktlich auf der .NET-Multicore-Konferenz sein konnte, um von dort aus live zu bloggen. Was auch gut geklappt und zudem viel Spaß gemacht hat. Und es war nicht nur informativ, sondern auch sehr unterhaltsam, Ralf Westphal und Bernd Marquardt gemeinsam auf der Bühne zu erleben. Denn neben der geballten fachlichen Kompetenz konnten die zwei auch mit Entertainment-Qualitäten überzeugen. Stellenweise habe ich mich an meine Jugend erinnert gefühlt, in der Statler und Waldorf auf dem Muppet-Show-Balkon Ähnliches abgeliefert haben.
prio.powerday: Microsoft Concurrency Coordination Runtime
Direkt nach Bernds Vortrag ist Ralf Westphal wieder dran und erzählt etwas zur Concurrency Coordination Runtime (CCR). Im Gegensatz zu Bernd geht es bei Ralfs Vortrag weniger um die Leistungssteigerung parallel programmierter Anwendungen als vielmehr um die optimale asynchrone Datenverarbeitung im parallelen .NET-Umfeld.
Die CCR ermöglicht ein neues Programmiermodell für parallel laufende Anwendungen. Ein sehr schöner Ausspruch von Ralf lautet übrigens: “Vergesst Threads!”, da Threads synchronisiert werden müssen, was Ralf nicht wirklich mag. Um das besser verdeutlichen zu können, schreibt er in Echtzeit verschiedene kleinere Programme. Sehr schlau!
Das Besondere an der CCR ist das Warteschlangenprinzip: Jeder Befehl oder jedes Datum wird im Hintergrund aus der Warteschlange ausgelesen und verarbeitet, sobald eine Ressource frei ist. Damit müssen keine expliziten Threads erzeugt und wieder beendet werden, da sich die CCR automatisch darum kümmert. Hierfür steht die DispatcherQueue-Klasse zur Verfügung.
Die CCR erlaubt sowohl den Einsatz des Standard-Threadpools als auch eigene Threadpools auf Dispatcher-Basis.
prio.powerday: Parallele Programmierung unter .NET 3.5
Nach der Mittagspause ist Bernd Marquardt ohne sein Alter Ego an der Reihe. Sein Thema: Parallele Programmierung mithilfe des .NET-Frameworks 3.5, und zwar per TPL.
Folgende Elemente kommen zum Einsatz:
- Parallele Erweiterungen für LINQ = PLINQ
- Schleifen parallelisieren: Die hierzu gehörige Klasse heißt System.Threading.Parallel. Schleifen werden auf mehrere Threads aufgeteilt werden, aber nur, wenn die einzelnen Schleifendurchläufe unabhängig voneinander sind. Dabei müssem die Indezies alle gleich sein. Am Ende der Schleife werden alle Threads synchronisiert. Fazit: Schleifenparallelisierung lohnt sich nur bei komplexen und großen Schleifen! Wichtig ist auch die richtige Verteilung einer Schleife auf die vorhandenen Prozessorressourcen. Dies gelingt, indem die einzelnen Schleifendurchläufe in kleinen Portionen verarbeitet werden.
- Aggregationen: Hierbei geht es um das Zusammenfassen von Ergebnissen. Dabei ist Locking meist erforderlich. Zwischenwerte werden über sogenannte ThreadLocateState weitergegeben. Der Ablauf sieht folgendes vor: Initialisierung, Zwischenspeichern der einzelnen Thread-Ergenisse und das abschließende Zusammenführen der Zwischenwerte inklusive Locking. Übrigens: Aufgrund des Zusammeführens der einzelnen Thread-Zwischenergebnisse kann ist bei der parallelen Ausführung zu Rundungsfehlern kommen und das Ergebnis weicht vom sequentiellen Programm ab.
prio.powerday: Multithreading mit .NET-Bordmitteln
Und weiter geht’s. Bernd und Ralf gehen jetzt näher auf das Thema Multithreading mit .NET-Bordmitteln ein. Hierbei gibt es verschiedene Aspekte:
- Statisches Threading birgt vor allem ein Problem: Es gibt statische Variablen, die von mehreren Threads gleichzeitig schreibend genutzt werden können.
- Threading mit instanzierten Klassen: Jeder Thread hat seine eigene Instanz, also zum Beispiel seine eigenen Variablen, was natürlich ein wenig mehr Ressourcen kostet.
- Steuerung von Threads: Hierbei geht es um die Priorisierung von Threads sowie das Starten, Pausieren und Stoppen von Threads. Die Herausforderung ist hier der jeweils richtige Zeitpunkt, ein Thread zu manipulieren. Außerdem muss man feststellen können, ob ein Thread gewollte beendet wurde. Dies kann per Bool’scher Variable erreicht werden.
prio.powerday: Einführung in die parallele Programmierung
Jetzt sind mit kaum einer halben Stunde Verspätung Ralf Westphal und Bernd Marquardt dran. Sie wollen uns erst mal erzählen, was parallele Programmierung eigentlich bedeutet.
Zunächst geht es um echte Basics wie Multithreading mit Single- und Multicores. Fakt ist: Multithreading allein bringt gar nichts, dafür sind mehrere Prozessoren und die Zerlegung eines Programms in parallel zu verarbeitenden Bereiche notwendig.
Eine weitere Herausforderung sind Latenzzeiten, die sich aus asynchroner Prozessorverarbeitung ergeben. Das lässt sich mithilfe einer Kombination aus Multithreading und Multitasking auf mehreren Prozessoren optimieren.
Es gilt aber zugleich, den Durchsatz zu erhöhen. Dies gelingt ausschließlich auf Multicore-Systemen.
Es gibt ein grundsätzliches Problem bei der Parallelverarbeitung: den Zugriff auf gemeinsame Ressourcen. Diese Herausforderung meistern Zugriffskontrollen mithilfe explizierter Sperren. Hierfür sperren zum Beispiel einzelne Tasks gemeinsamen Speicher. Allerdings müssen die Zeitspannen und die Granularität dieser Sperren genau passen. Ein große Gefahr hierbei sind übrigens mögliche Deadlocks, die gerade bei parallel programmierten Anwendungen erst zur Laufzeit auftreten. Deadlocks lassen sich durch dieselbe Sperrreihenfolge vermeiden.
prio.powerday: Multicore-Programmierung unter .NET
Kaum dass ich aus Salzburg zurück bin, sitze ich hier im Konferenzhaus in der Lazarettstraße, München, und nehme an der Multicore-Konferenz für .NET-Entwickler teil, die im Rahmen der prio.powerdays stattfindet.
Den Anfang macht Rami Radi von Intel, der die Einführungsrede hält und die Anwesenden auf das Thema Multicore einstimmen will.
Rami beginnt seinen Vortrag mit Hardware, nicht mehr Software. Namentlich spricht er über den Core i7-Prozessor, der ja im höchsten Maße multithreading-tauglich ist. Core i7 verarbeitet nämlich pro Prozessorkern zwei Threads simultan.
Die nächste Folie zeigt die ganze Vielfalt der Intel-Entwicklertools, über die ich hier schon ausführlich berichtet habe, also über Compiler, VTune etc.
So, jetzt wird’s ernst. Rami spricht über die Parallelprogrammierung im .NET-Umfeld, was seiner Meinung nach nicht einfach ist (wären wir sonst hier?). Zu den Herausforderungen gehören unter anderem falsch genutzter Speicher, zu viele und zu wenige Threads, gemeinsam genutzte Speicherbereiche, Load Balancing und viele andere. Wie gut, dass es für diese “Issues” die passenden Tools gibt wie den VTune Performance Analyzer.
Nach der Konferenz ist vor der Konferenz
Sodala, jetzt bin ich wieder im Büro, nachdem ich mich zwei Tage lang in Salzburg herumgetrieben habe, um auf der Intel Software Conference 2009 die Trends und Tools des Jahres 2009 aus Intel-Sicht kennenzulernen. Ok, Parallel Studio war hier schon das ein oder andere Mal Thema, aber aus erster Hand Infos rund um die geplante Entwickler-Suite präsentiert zu bekommen, ist schon ein Unterschied.
Auf der Konferenz habe ich auch James Reinders zum ersten Mal live erlebt, und in Echt ist er noch authentischer als in seinen Videos. Zu erzählen hat er sowieso eine ganze Menge über Parallel Studio, das übrigens am 26. Mai 2009 auf den Markt kommen soll. Zunächst zwar ohne Parallel Advisor, aber dafür inklusive Parallel Composer, Parallel Inspector und Parallel Amplifier. Und was es mit dem ominösen Ct-Projekt auf sich hat, haben wir von James ebenfalls erfahren.
Ansonsten gab es detaillierte Infos zu den Tools (samt Demos, die ich hoffentlich noch nachliefern kann) sowie eine kleine Einführung in Visual Studio 2010. Und warum Nero pro Jahr rund 50 Millionen Software-Titel verkauft, haben wir ebenfalls gelernt.
Ach ja: Nicht, dass es mir langweilig würde diese Woche. Am morgigen Donnerstag findet hier in München der prio.powerday zum Thema Multicore-Programmierung im .NET-Umfeld statt. Ich werde auch von dort Livebloggen und bin schon sehr gespannt, was Rami, Don, Bernd und Ralf zu erzählen haben. So, stay tuned …
ISC’09: die Zukunft der parallelen Programmierung
Wie im richtigen Leben gehört dem Chef das letzten Wort. Daher kommt James Reinders nochmals auf die Bühne und wagt einen Blick in seine Glaskugel.
Status quo aus Intel-Sicht sind die HPC-basierten Tools der Gegenwart, die permanent weiterentwickelt werden. Daneben wird es sehr bald (wohl im Mai) Parallel Studio geben für den Mainstream-Entwickler. Und drittens sind die vorhandenen Tools einer ständigen Evolution unterworfen (so kommt ein verbesserter Compiler irgendwann im Juni auf den Markt).
Die Evolution des Parallel Studio umfasst folgende Dinge:
- der Parallel Advisor wird wichtiger Bestandteil der Suite
- beste Kompatibilität mit Windows 7 und Visual Studio
- Unterstützung der nächsten Microsoft Concurrency Runtime
- Ergänzungen (was immer das bedeutet)
Den dritten Teil seines Vortrags leitet James mit einem Traum ein:
If you focused on “data parallel programming”, could you make it easier for the program to be deterministic and scale?
ISC’09: Intel Parallel Amplifier im Detail
So, genug genetzwerkt, jetzt wird es wieder ernst auf der Intel Software Conference 2009 in Salzburg. Vor der Pause hat Akyil Levent eine Menge über Parallel Inspector erzählt, jetzt ist er mit Parallel Amplifier dran.
Ein sehr schöner Einstieg in das Thema Tuning ist folgendes Zitat: “Ich weiß, wie ich vier Pferde dazu bringe, einen Wagen zu ziehen. Wie aber geht das mit 1024 Hühnern?” Das ist eine wirklich passende Analogie zur Optimierungsarbeit beim parallelen Programmieren. Denn es gibt so viele Fallen, in die man beim Multithreading tappen kann: nicht-skalierender Code, Deadlocks oder Data Races zur Laufzeit und vieles mehr.
Dafür gibt es den Parallel Amplifier, der Flaschenhälse findet, die Skalierbarkeit der Anwendung ermittelt und mehr. Es hilft also Entwicklern und Programmierern, die parallele Struktur und das parallele Verhalten ihrer Anwendung besser zu verstehen.
Wie schon der Composer und Inspector, integriert sich Parallel Amplifier in Visual Studio und findet folgende Probleme:
- Wo verbraucht meine Anwendung die meiste Zeit?
- Wann gehen die Prozessoren in den Idle-Modus?
- Wo gibt es ungewollte Wartezeiten?
Sobald Amplifier die möglichen Fehler gefunden hat, lassen sich die entsprechenden Quellcode-Stellen per Mausklick öffnen und auf die Fehler hin überprüfen.
