12 Thesen und Antithesen zur Multicore-Programmierung
Gestern auf der OOP 2009 hielt Professor Walter F. Tichy von der Uni Karlsruhe einen Vortrag mit dem Titel “Herausforderung Mehrkernsysteme”. Darin beschäftigte er sich mit diversen Aspekten der Parallelprogrammierung. Und das zu Recht, denn das Thema scheint ein echter Renner zu sein; der Raum war auf jeden Fall gut gefüllt.
Im Laufe seines Referats stellte Professor Tichy mehrere Thesen in Sachen Parallelprogrammierung auf, die ich hier ein wenig aufdröseln will.
These #1: Die Informatik erlebt gerade eine Evolution: Weg von der sequenziellen Programmierung hin zur parallelen Entwicklung. Parallelität gab es bis dato nur in Nischenbereichen wie Numerisches Rechnen, Betriebssystemen und Datenbanken und Parallelität auf Instruktionsebene. Meine Antithese dazu: Stimmt!
These #2: Es gab immer wieder spezielle Parallelrechner wie den Atanasoff-Berry-Rechner von 1942, der ausschließlich lineare Gleichungen mit 30 Koeffizienten lösen konnte. Dazu gehörte aber auch der Illiac-IV, ein SIMD-Rechner mit verteiltem Speicher und 64 Prozessoren. Dieser Großrechner wurde 1976 gebaut und war bis 1981 der schnellster Rechner der Welt. Natürlich erwähnte Tichy auch den Cray-1 Vektorrechner, der ebenfalls aus dem Jahr 1976 stammt und wohl den bekanntesten Vertreter der prähistorischen Parallelrechner darstellt. Das Alles (und viel mehr) mündete schließlich in riesigen Clustersystemen der Gegenwart, die allesamt auf der Webseite Top500.org zu bestaunen sind. Meine Antithese dazu: Eine schöne Liste!
These #3: Es gibt neben Intel-CPUs wie Core 2 Quad oder Core i7 weitere Parallelprozessoren, die allerdings (beispielsweise die Grafik-CPU Geforce 8 von Nvidia) hauptsächlich für Spezialbereiche konzipiert sind. Meine Antithese dazu: Wie sagte erst kürzlich ein bekannter Chefentwickler zu mir: “CUDA und die angeblich enorme Rechenleistung der Geforce-GPUs ist vor allem eins: Marketing!”
These #4: Die Moore’sche Regel hat eine Variation erfahren, die wir an der Uni Karlsruhe sogar ein wenig verfeinern wurde: “Die der Anzahl Prozessoren pro Chip wird sich mit jeder Chip-Generation bei etwa gleicher Taktfrequenz verdoppeln”. Meine Antithese dazu: Ja, das sagt Intel auch. Dann wird es wohl stimmen …
These #5: Was sollen wir mit all den Kernen nur anfangen, die uns in Zukunft zur Verfügung stehen? Die Antworten lieferte Professor Tichy postwendend selbst: automatische Protokollführer; inhaltsbasierte Bildersuche mithilfe einer Datenbank; intuitive Schnittstellen mit Bild- und Sprachverarbeitung; vorausschauende Anwendungen, die “ahnen”, was der Benutzer will; Modellierung des Benutzers und der Umgebung; Erhöhung der Zuverlässigkeit (Redundanzen). Meine Antithese dazu: Wie wäre es mit weiteren Beispielen: Videoschnitt, Bildbearbeitung, 3D-Spiele, skalierende Betriebssysteme und Videoencoding, um nur einige zu nennen.
In der Parallelprogrammierung steckt die Zukunft!
Die Überschrift dieses Beitrags ist das Fazit eines sehr interessanten Artikels von Walter F. Tichy, seines Zeichens Professor für Softwaretechnik an der Uni Karlsruhe. In seinem Gastbeitrag auf Computerzeitung.de spricht er nämlich von der Herausforderung Multicore-Programmierung und den Chancen, die sich daraus ergeben. Dabei nennt er einerseits ein paar sehr wichtige Aspekte, andererseits vermisst er ein, zwei Dinge, die jedoch entgegen seiner Aussagen bereits existieren. Aber der Reihe nach.
Wichtig erscheint mir auf jeden Fall die Feststellung, dass “in Zukunft [...] Parallelrechner ungefragt und flächendeckend zur Verfügung stehen” werden. Ganz klar, das ist der Trend, und wenn man sich die Roadmap von Intel ansieht, wird schnell klar, dass der Core i7 nur der Anfang der Multicore-Ära ist.
Ebenso wichtig sind die potenziellen Multicore-Anwendungen, die Professor Tichy aufzählt: Dazu gehören natürlich Medienprogramme wie DivX und 3D-Spiele wie Crysis oder Sacred 2 (und Bildbearbeitungstools wie Silver Efex Pro von Nik Software). Aber auch weniger spektakuläre Anwendungen wie Logistikplaner, Tabellenkalkulation, Suchalgorithmen und Sicherheitsüberprüfungen profitieren vom Multithread-Code. Zusammengefasst könnte man mit Tichys Worten sagen:
Diejenigen Firmen, die jetzt die richtigen Anwendungen identifizieren und parallelisieren, werden in Zukunft zu den Gewinnern gehören, zumal Beschleunigung durch Abwarten – das heißt: das Setzen auf weiter steigende Taktfrequenzen – nicht mehr funktioniert.
Multicore-Powerday 2009 am 23. April in München [Upd]
Jetzt ist es tatsächlich soweit: Die Neue Mediengesellschaft Ulm (Dotnetpro, Database pro und PHP Journal) veranstaltet gemeinsam mit Penton Media den ersten Multicore-Powerday. Die Subheadline sagt im Grunde schon alles: “Multicore-Programmierung für .NET-Entwickler”.
Und dieser “Krafttag” wird es wohl in sich haben. Es geht unter anderem um folgende Fragen:
- Wie nutze ich aktuelle und zukünftige Multicore-Prozessoren optimal für meine Anwendungen?
- Was ist die Concurrency Coordination Runtime und welche Aufgaben übernimmt sie?
- Welche Bedeutung haben die Parallel Extensions für das .NET-Framework und wie setze ich sie am besten ein?
- Wie erstelle mithilfe von F# parallel programmierte Anwendungen?
Diese und viele weitere Fragen werden auf der großen .NET-Konferenz beantwortet. Und zwar von bekannten Größen der Branche wie Ralf Westphal und Bernd Marquardt, beide ihres Zeichens Microsoft MVP.
Falls Sie also zu den .NET-Entwicklern gehören, die unbedingt mehr wissen wollen (oder müssen) zum Thema Multicore-Programmierung, sollten Sie den 23. April schon mal ganz fett und dick im Kalender markieren.
Spartipp: Geben Sie bei der Anmeldung zum Multicore-Powerday einfach den Gutscheincode PPMC9SDB ein und schon sparen Sie 100 Euro. Ist das nix?!
Update: Sodala, jetzt ist auch die zugehörige Webseite online.
Ist für Windows 7 ein neuer Taskmanager notwendig?
Gerade eben habe ich einen interessanten Blog-Beitrag zum Thema Windows 7 und dessen Multicore-Fähigkeiten gefunden. Da das nächste Betriebssystem aus dem Hause Microsoft (das eigentlich gar nicht so richtig neu ist) mit bis zu 256 Prozessorkernen zurechtkommen wird, stellt sich Blog-Autor Doug Holland die Frage, ob der Windows Taskmanager noch das passende Tool ist für solch eine Fülle an CPUs.
Das ist sicherlich nicht ganz ernst gemeint, macht aber die Herausforderungen sehr anschaulich, vor der die Entwicklergemeinde stehen wird, sobald Windows 7 auf dem Markt ist und das Programmieren von neuer Software für maximal 256 Cores ansteht. Dann gibt es nämlich nur noch eins: die richtigen Tools kaufen und parallelisieren, was das Zeug hält. Andernfalls wird aus dem Multicore-Riesen ein lahmer Singlecore-Zwerg, der von der sequenziell programmierten Anwendung jämmerlich ausgebremst wird.
Wie gut, dass es hierfür schon einiges gibt und weitere Tools kommen werden. Die Rede ist beispielsweise von den Threading Building Blocks, Thread Checker, Parallel Studio, Visual Studio 2010 und weiteren nützlichen Hilfsmitteln, mit denen die Parallelprogrammierung zwar kein Klacks wird, vieles sich aber vereinfachen lässt.
Ach ja: Für das Problem mit dem unterdimensionierten Windows Taskmanager hat einer der Kommentatoren einen nützlichen Tipp parat: Virtualisierung. Soll heißen, dass sich einfach mehrere Prozessorkerne zu einem virtuellen Prozessor zusammenfassen lassen. Dann passt die Taskmanager-Anzeige auch wieder auf einen 19-Zöller und die Anschaffung eines 30-Zoll-Monitors kann noch einmal verschoben werden …
Entwicklergemeinde trifft sich auf der OOP 2009
Die Software-Entwicklergemeinde trifft sich vom 26. bis 30. Januar auf der OOP 2009 im ICM der Messe München. An fünf Tagen wird es um die ganze Bandbreite der (objektorientierten) Programmierung und Software-Entwicklung gehen. Namhafte Redner geben in Vorträgen und Workshops Auskunft darüber, wohin die Entwicklerreise geht. Zu den Highlight zählen unter anderem:
- Ursprung des Computers (Horst Zuse!)
Daneben gibt es interessante Ganztagskurse, die am Montag und am Freitag stattfinden. Und wer es besonders lange mag, dem seien die “Night School Sessions” empfohlen.
Buchtipp: Multicore-Programmierung lernen mit Intel
Für alle, die sich mit dem Thema Multicore-Programmierung autodidaktisch auseinandersetzen wollen, haben wir heute einen Buchtipp: “Multicore-Programmierung” von Shameem Akhter und Jason Roberts. Für alle, die mehr auf das Original stehen, sei das Buch in Englisch bei Amazon empfohlen (54,90 Euro, ISBN-10: 3939084700) oder die deutsche Übersetzung “Multicore-Programmierung”, die es bei Entwickler.press für denselben Preis zu kaufen gibt.
Das Buch ist unterteilt in elf Kapitel, die sich allesamt mit dem Thema Multicore-Programmierung und Multithreading beschäftigen. Im ersten Abschnitt geht es zunächst um die Grundzüge von Multicore-Architekturen und die Frage, was das Amdahlsche Gesetz mit dem Ganzen zu tun hat.
Kapitel Nummer 2 betrachtet Threads im Speziellen und zeigt, wo sie eine Rolle spielen und wie hier die Virtualisierung ins Spiel kommt. Der dritte Teil des Buches erläutert dann, wie ein Programm in Threads zerlegt werden sollte, um ein Höchstmaß an Parallelität in die Anwendung zu implementieren.
Anschließend geht es ans Eingemachte: Shameem und Jason betrachten die einzelnen Schritte, die bei der Multithread-Programmierung anfallen, also die Synchronisierung von Daten und Aufgaben, und erklären auch, wie Deadlocks entstehen und wie man diese vermeidet. Kapitel fünf und sechs widmen sich den Threading-Modellen, also den Windows- und POSIX-Threads sowie OpenMP, die wir auch schon betrachtet haben.
Beliebte Fehler bei der Parallelprogrammierung
Parallelprogrammierung ist keine einfache Disziplin und birgt eine Menge Fehlerquellen. Das beginnt beim grundsätzlichen Design der Anwendung und endet bei falsch gesetzten “Locks”. Daher folgen an dieser Stelle die beliebtesten Fehler der Multicore-Programmierung. Und was man dagegen tun kann, erfahren Sie hier auch.
Zunächst einmal helfen unsere fünf Multicore-Regeln, die wir Ende letzten Monats aufgestellt haben. Die wichtigste davon lautet beim Software-Design: Denke parallel! Denn nur so hält man am Schluss eine Anwendung in den Händen, die sich mithilfe der passenden Tools bestmöglich parallelisieren lässt.
Eine beliebte Fehlerquelle ist ein Überangebot an Threads, vor allem dann, wenn Sie diese “manuell” programmieren, so wie im Falle von Pthreads. Daher sollte man durchaus sparsam mit dem Erstellen von Threads umgehen, denn nur eine ausgewogene Balance von parallelem und seriellem Quellcode bringt die erwünschten Leistungsschübe. Oder man bedient sich nützlicher Tools wie Intel TBB, die Threads automatisch generieren.
