OOP 2011: Stephen Blair-Chappell über Chancen und Grenzen der Parallel-Programmierung
Am gestrigen Dienstag hatte ich auf der OOP 2011 die Gelegenheit, den sehr interessanten Vortrag „Parallelising Legacy Programs“ von Stephen Blair-Chappell, Mitarbeiter der Intel Compiler Labs zu verfolgen. Zu Deutsch: Es ging um das Thema „Parallelisieren bestehender Anwendungen“. Klingt zunächst recht trocken und sehr theoretisch. Stephen hat – trotz vieler Code-Beispiele – seinen Vortrag aber didaktisch sehr gut aufgebaut, so dass auch Einsteiger viel nützliches Wissen mitnehmen konnten.
Im Übrigen hatte ich auch die Gelegenheit, nach der Session mit Stephen persönlich zu sprechen und ein kurzes Video-Interview zu führen. Das werde ich selbstverständlich auch in Kürze auf dieser Seite veröffentlichen.
Fallstricke
Zurück aber zu den Vorteilen und Fallstricken der Parallel-Programmierung. Stephen konnte anhand früherer Projekte sehr eindrucksvoll demonstrieren, dass der erste Schritt der Parallelisierung immer darin besteht, den vorhandenen Code zu verstehen und zu analysieren. Klingt banal, in der Praxis aber passieren genau hier die meisten Fehler. So verfallen auch erfahrene Programmierer der Verlockung, vorschnell neuen Code zu implementieren, anstatt frühere Schwachstellen zu korrigieren. Der Effekt: Trotz erfolgreicher Ausrichtung auf mehrere Prozessorkerne zeigen die Anwendungen keinen nennenswerten Geschwindigkeitsgewinn.
4-Stufen-Methode
Dann ist die Ursachenforschung kompliziert und sehr aufwändig. Stephen erklärte, dass mitunter sogar ein aktiver Virenscanner als Bremsklotz einer Parallel-Anwendung fungieren kann. Diese Dinge sollte man demnach schon beim Check des seriellen Codes im Auge behalten. Daraus ergibt sich für Programmierer eine 4-Stufen-Methode bei der Parallelisierung, die grundsätzlich eingehalten werden sollte:
- Analyse des seriellen Codes hinsichtlich möglicher “Hotspots”
- Implementierung von Parallelkonstrukten auf Basis passender Programmiermodelle
- Fehlersuche mithilfe geeigneter Tools
- Optimierung des neuen, parallelisierten Codes
Die für die Implementierung gewählten Programmiermodelle (Sprache, Bibliotheken, Methoden) sind dabei sowohl vom ursprünglichen Code als auch von der Zielsetzung des Projektes abhängig. Stephen konnte hier in unterschiedlichen Szenarien beispielsweise die Vorteile von Cilk und OpenMP erläutern und verdeutlichten, dass sowohl der Compiler als auch die Hardware eines Systems über die Performance der Anwendung entscheiden.
Am Ende des Vortrags ging Stephen auf ein Thema ein, das bei aller Begeisterung für Multicore gerne übersehen wird: Auch Parallel-Programmierung ist nicht immer der Weisheit letzter Schluss. In einigen Fällen reicht es aus, den seriellen Code zu optimieren. Aber diese Frage sollte eigentlich schon während der Analyse beantwortet werden.
Ausblick auf die CES, Sandy Bridge und zwei nützliche Tools
Keine Ahnung, wie viele Menschen Ihnen in den letzten Tagen „Ein gutes neues Jahr!“ gewünscht haben. Aber vermutlich waren es viele, und ganz sicher werden sie Recht behalten. Denn das Jahr 2011 wird für Parallel-Programmierer und Spiele-Entwickler Maßstäbe setzen!
In wenigen Tagen wird Intel während der CES in Las Vegas die neue Prozessorgeneration Sandy Bridge offiziell vorstellen. Vor Ort werden dann auch gleich ein paar Hardware-Hersteller erste Notebooks mit den neuen Recheneinheiten zeigen.
Die Prozessor-Architektur von Sandy Bridge wird vor allem in puncto Multimedia-Performance alle Vorgänger der Nehalem-Bauweise in den Schatten stellen. Sandy Bridge integriert den Grafikkern (GPU) in die CPU bei einer Strukturbreite von 32 Nanometern. Dank der integrierten Encoding-Einheit lassen sich Videos wesentlich schneller konvertieren als beispielsweise mit bekannten Core-i5-Prozessoren.
Die technologischen Neuerungen von Sandy Bridge und die daraus resultierenden, erweiterten Möglichkeiten für Parallel-Computing sind Anlass genug, dieses Blog wiederzubeleben. Ich werde Sie ab sofort regelmäßig mit News, technischem Background und Veranstaltungshinweisen versorgen, die Ihnen den Programmieralltag etwa erleichtern.
Zunächst aber darf ich Ihnen zwei neue, sehr nützlich Tools empfehlen, die Intel im Rahmen der Partnerprogramme veröffentlich hat und vor allem Entwickler von Media- und Videoanwendungen adressieren.
Das Intel Media Software Development Kit in der Version 1.5 ist ein plattformübergreifendes SDK, das Ihnen hilft, auf einfache Weise leistungsstarke und schnelle Videoanwendungen zu entwickeln. Das Tool-Paket bietet Ihnen drei Highlights:
- Codecs für Hardwarebeschleunigung: Sie greifen auf Video-Codecs zu, die für Intel Multicore-Prozessoren und Intel HD Graphics optimiert wurden und bestmögliche Performance bieten
- Einheitliches API für unterschiedliche Plattformen: Weniger Code und weniger Komplexität durch ein universelles API, das viele PC-Plattformen unterstützt, darunter selbstverständlich auch die zukunftsträchtigen Intel Graphics- und Multicore-Architekturen.
- Support und Add-Ons: Schneller optimale Ergebnisse erzielen dank nützlicher Features wie Video-Pre-Processing, Decodieren und Encodieren
Sie können das Media Software Development Kit kostenlos laden und installieren. Sinnvoll ergänzt wird das SDK durch das Intel Media Checker Software Assessment Tool. Zugegeben, eine grauenhafte Bezeichnung, aber das Tool ist überaus nützlich. Denn damit stellen Sie beispielsweise sicher, dass Sie das SDK korrekt in die Anwendungen einbinden. Zudem fungiert es als Tutorial, indem es die Funktionen und Technologien des SDK erläutert. Also für die ersten Schritte mit dem SDK sicherlich genau richtig. Und kostenlos ist es natürlich auch. Viel Erfolg damit!
Multiplayergames twittertauglich machen
Dass Multiplayergames eine riesige Anziehungskraft ausüben, ist ja nichts Neues. Es ist schließlich viel aufregender und spannender, sich mit richtigen “Gegnern” zu messen als nur mit dem doofen Computer. Wie aber kommt man an adäquate Gegen- oder Mitspieler heran? Nun, hierzu kann man entweder einer der existierenden Communities beitreten (die aber meist recht übersichtlich sind) oder man macht sich Social-Media-Dienste wie Twitter oder Facebook zu Nutze.
Nun ist es aber leider so, dass kaum ein Spiel den Zugriff auf diese Dienste implementiert hat, was jedoch mit ein paar Codezeilen an der richtigen Stelle im Quellcode des Spiels problemlos zu machen ist. Sagt zumindest Mitchell Lum von Intel, der in seinem Blogpost anhand eines C#-Beispiels zeigt, wie man aus dem laufenden Spiel heraus twittern kann. Das ist übrigens nicht nur für Multiplayer ein echter Mehrwert, sondern auch für Spieleentwickler, die auf diesem Weg den Bekanntheitsgrad ihrer Titel mithilfe von Twitter erhöhen können.
Dann schaut euch den Blogbeitrag samt Codebeispiel einfach mal in Ruhe an.
Parallel Talk: Warum Ct und Rapidmind gut zusammenpassen
Auf dem diesjährigen IDF in San Francisco wurde ich selbst “Opfer”, als ich mich unversehens vor dem Whiteboard von Aaron Tersteeg wiederfand. Aber zum Glück ging es nicht nur mir so, sondern auch unter anderem Stefanus, Michael und Anwar von Intel, die etwas sagen sollten über die Ct-Technologie und warum diese mit den Paralleltechniken von Rapidmind so gut zusammen passt.
Nur so viel: Ct soll noch in diesem Jahr als Beta verfügbar sein und Software-Entwicklern dabei helfen, ihre Anwendungen noch eleganter zu parallelisieren als bisher. Und genau dieses Bestreben verfolgen auch die Jungs von Rapidmind. Das dürfte wohl der wesentliche Grund gewesen sein, warum Intel und Rapidmind seit Ende August gemeinsame Sache machen.
Aber am besten lassen wir Stefeanus, Michal und Anwar selbst zu Wort kommen …
Parallel programmieren für 100 $: Intel-Gewinnspiel
Intel nennt es “Threading Challenge 2009″, hat sich dafür den recht griffigen Claim “Code your future” ausgedacht und mittlerweile die zweite Phase des Programmierwettbewerbs gestartet. Dieser zweite Abschnitt umfasst wieder sechs Aufgaben, die alle möglichst gut gelöst werden sollen. Und zu gewinnen gibt es natürlich auch etwas: Jede am besten gelöste Aufgabe ist Intel 100 US-Dollar wert, die in Form eines Visa-Geschenkcoupons überreicht werden. Und der Gesamtsieger pro Phase kann darüber hinaus ein schickes Netbook abgreifen. Die genauen Regeln dazu findet ihr hier.
Die erste Aufgabe beschäftigt sich übrigens mit der Matrizen-Multiplikation, und zwar auf Basis des Strassen-Algorithmus. Hierfür muss ein kleines parallelisiertes Programm geschrieben werden, das auf einer vorgegebenen seriellen Lösung des Problemes basiert. Mithilfe des Strassen-Algorithmus ist also die parallele Version der seriellen Anwendung zu programmieren. Dabei müssen bestimmte Dinge wie Rumpf der Hauptfunktion erhalten bleiben, andere Dinge wie das Reservieren von notwendigem Speicher dürfen (und müssen) angepasst werden.
Zur Berurteilung der Güte der eingereichten Lösung wird übrigens die Zeit herangezogen, die das kleine Programm für die Matrizenmultiplikation benötgit. Da heißt es also sich anstrengen, um eine möglichst kurze Laufzeit herauszubekommen. Mehr Infos dazu bekommt man auf der Wettbewerbsseite. Viel Spaß und Glück beim Programmieren!
Ach ja: Die Intel Threading Building Blocks könnten beim Lösen der Aufgabe helfen. Nur so als kleiner Tipp …
GDC09: Wie Programmierer von Dualen Zahlen profitieren
Vor einer Woche hatte ich angekündigt, dass wir uns die Session “Dual Numbers: Simple Math, Easy C++ Coding and Lots of Tricks” ansehen werden. Und genau das haben wir heute getan. Nur so viel: Tough stuff!
Damit wir hier nix Falsches erzählen, konnten wir Gino van den Bergen zu einem Interview überreden, damit er uns etwas über Duale Zahlen erzählt: Worum es in seinem Vortrag ging, warum Spieleentwickler auf Duale Zahlen setzen sollten und was das Ganze mit Larrabee zu tun hat.
Nur soviel: Es geht um “Clean Code”, um die Vereinfachung der Differentialrechnung, und andere schöne Dinge, mit denen vor allem Spieleprogrammierer zu tun haben.
Und jetzt: Film ab!
Mögliche Thread-Modi und deren Folgen
Multicore-Programmierung ist sicherlich kein einfaches Ding. Zu viel kann dabei passieren und schiefgehen, wenn man bestimmte Regeln nicht beachtet. Daher starten wir heute einen Mehrteiler, der sich mit den Details der Multicore-Programmierung beschäftigt. Im ersten Teil geht es um die fundamentale Frage, welche Zustände ein Thread während des Programmablaufs annehmen kann.
Im ersten Schritt wird beispielsweise vom Thread Manager ein Thread erzeugt und in den Bereit-Zustand versetzt (“ready”). Dort verharrt der Thread so lange, bis er eine Anweisung, eine Funktion oder ähnliches ausführen soll. Darum kümmern sich entsprechende Programmanweisungen wie zum Beispiel die Pragma-Methoden der OpenMP-basierten Programmierung.
Im zweiten Schritt kommt es zur Ausführung der entsprechenden Quellcodestelle. Währenddessen muss der betreffende Thread möglicherweise auf einen anderen Thread oder ein Datum eines parallel ablaufenden Threads warten. Dann begibt er sich in den Wartend-Modus, bis der benötigte Thread beendet ist oder dessen Ergebnis vorliegt. Anschließend wird der angehaltene Thread weiter ausgeführt oder wieder in den Bereit-Zustand versetzt, da der Thread zu einem späteren Zeitpunkt nochmals benötigt wird.
Ach ja: Gerade dieser Wartend-Modus bereitet vielen Programmierern erhebliche Probleme, da hierbei Dead Locks, Data Races oder andere unvorhersehbare Ereignisse auftreten können. Wie gut, dass es hierfür Tools wie den Thread Checker oder Parallel Inspector gibt, die solche Schwachstellen aufspüren können.
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.
Mac OS X 10.5 (Leopard) fährt voll auf Multicore ab
J, ja, es ist schon ein paar Tage her, dass Mac OS X 10.5, auch bekannt als Leopard, das Licht der Welt erblickt hat. Aber ich habe gerade ein paar sehr interessante Details bezüglich der Multicore-Affinität des Apple-Betriebssystems entdeckt. Und so richtig viel darüber habe ich im Web nicht gefunden.
Hardware-seitig bietet Apple ja mit dem Mac Pro die volle Mehrkerntechnik von Intel: Acht Prozessorkerne beschleunigen vor allem die Bild- und Videobearbeitung, aber auch für Apple-eigene Anwendungen ist der Intel Xeon Prozessor, eine Quadcore-CPU mit maximal 3,2 GHz, nützlich.
Von dieser Mehrkern-Architektur profitieren unter anderem Programme wie Mail, das Adressbuch und die Verwaltung der Schriftensammlung, indem anfallende Aufgaben auf die vorhandenen Ressourcen möglichst optimal verteilt werden. Darum kümmert sich übrigens die neu programmierte Ablaufsteuerung von Leopard.
In Sachen Netzwerk hat sich Apple ebenfalls Gedanken gemacht: So wurde ein multithreading-fähiger Netzwerkstapel implementiert, der die Ein- und Ausgabeanfragen des LANs schneller verarbeiten kann. Außerdem wurde die indizierte Suchfunktion Spotlight beschleunigt, genauso wie die Wörterbuchfunktion von Mac OS X 10.5. Dies hat vor allem mit der objektorientierten API Cocoa zu tun, die ebenfalls für den Multicore-Betrieb optimiert wurde.
Optimierte Compiler helfen beim Parallelisieren
Auf dem Software Dev Blog war schon von diversen Entwickler-Tools die Rede, die Programmierern beim Erstellen multicore-tauglicher Anwendungen helfen sollen. Ob das die Threading Building Blocks sind, der Thread Checker, Hochleistungsbibliotheken oder der VTune Performance Analyzer – stets geht es darum, das Optimum aus seiner Software herauszuholen, falls diese auf Multicore-Plattformen möglichst gut skalieren soll.
Wie aber sieht es mit den fundamentalen Tools aus, die bei der Programmierung an erster Stelle stehen, also etwa den Compilern, mit denen sich der Quellcode in eine ausführbare Anwendung verwandeln lässt? Nun, auch hierfür gibt es multicore-optimierte Lösungen, die sich vor allem an C++- und Fortran-Programmierer richten. Das Ganze gibt es sogar als komplettes Entwicklerpaket, das neben dem C++-Compiler die TBB-Suite umfasst, die Integrated Performance Primitives und die Math Kernel Library.
Praktisch an dem Intel C++-Compiler für Windows sind vor allem zwei Dinge: Zum einen lässt er sich direkt in Visual Studio einbinden, was das Kompilieren innerhalb der gewohnten Umgebung ermöglicht. Und zum anderen ist der Compiler für Multicore-Plattformen optimiert. Das bedeutet, dass der Quellcode auf mögliche Parallelitäten hin untersucht wird. Findet der Compiler entsprechende Programmabschnitte, fügt er automatisch die passenden Konstrukte und Funktionen ein, die den seriell programmierten Abschnitt parallelisieren.
Neu an der Version 11 des Intel C++-Compilers sind übrigens unter anderem die eingebauten Lambda-Funktionen, OpenMP 3.0 und die Unterstützung von dezimalen Fließpunktoperatoren und -registern. Und natürlich gibt es die Intel Compiler auch für Linux (inklusive Eclipse-Unterstützung) und für Mac OS X (in Verbindung mit XCode).
Von Single-Threading bis zur Multicore-Programmierung
Betrachtet man die Evolution der Programmiermethoden der letzten Jahre, hat sich hier viel getan. Über Jahrzehnte hinweg galt die sequenzielle Programmierung (mal abgesehen von den HPC-Jungs) als konform und anerkannt. Jede Aufgabe, die es zu programmieren galt, wurde streng linear ausgeführt und erforderte daher keine parallelen Ansätze.
Mit der Einführung neuer Betriebssysteme wie Microsoft Windows und besserer Prozessoren wie dem Intel Pentium MMX standen auf einmal im Desktop-Segment ganz neue Möglichkeiten zur Verfügung: Mit Multitasking konnten zeitversetzt von einem Prozessor mehrere Aufgaben anscheinend gleichzeitig erledigt werden. Und das Multithreading erlaubte es dank neuer Befehlssätze (SSE), Daten gleichzeitig zu verarbeiten, wenn diese keine Abhängigkeit zueinander aufwiesen. Dazu gehört auch die SIMD-Architektur, die beispielsweise gleichartige Operationen in großen Integer-Registern parallel ausführen kann.
Dann wurde mit dem Intel Pentium 4 HT der erste Prozessor für den Verbrauchermarkt vorgestellt, der auf Basis der Hyperthreading-Technik zwei Aufgaben gleichzeitig in einem Prozessorkern ausführen konnte. Dies ermöglichte ganz neue Anwendungen, da deutlich mehr Rechenleistung auf Standard-PCs zur Verfügung stand. Die HT-Technik wird auch als simultanes Multithreading bezeichnet.
Mit dem Aufkommen von Dual- und Quadcore-Prozessoren im Massenmarkt ließen sich erstmals Anwendungen zur Laufzeit in unterschiedliche Aufgaben zerlegen, die dann auf mehreren CPU-Cores gleichzeitig, also parallel, verarbeitet werden können. Dies erfordert allerdings von den Software-Entwicklern sehr viel mehr Denkarbeit, um ein Programm von Haus aus parallel zu entwickeln. Zudem sollte er auf Software-Tools setzen, die ihn bei der parallelen Programmierung so gut wie nötig und möglich unterstützen.
TU München verstärkt ihr Multicore-Engagement
Erst am Freitag habe ich mich mit der Frage beschäftigt, warum in diesem Land zu wenig Geld und zu wenig Ressourcen in Sachen Multicore-Ausbildung gesteckt werden. Allerdings setzen einige Universitäten und Fachhochschulen bereits auf die Mehrkerntechnik und haben ihre Lehrpläne dahingehend optimiert.
So wie die TU München, die schon seit längeren mit Intel in Sachen Multicore-Programmierung zusammenarbeitet. Hierzu habe ich auf Blip.tv ein sehenswertes Video mit Professor Doktor Arndt Bode gefunden, dem Vizepräsidenten der Technischen Uni zu München.
In diesem sechsminütigen Videochat erfährt man diverse aufschlussreiche Dinge:
- Nicht nur Informatikstudenten sollten sich mit dem Thema Multiprozessor-Architektur beschäftigen, sondern auch die anderen Fakultäten. Und klar, programmieren für mehrere CPU-Kerne sollten sie auch können.
- Steigerungsraten in Sachen Rechenleistung lassen sich nur noch mithilfe mehrerer Prozessorkerne erzielen und der damit einhergehenden Threads, die parallel verarbeitet werden können. Denn die Zeiten der Gigahertz-Mania sind endgültig vorbei (sic!).
Ausbildungslücken bei der Multicore-Programmierung
Ein Interview auf Elektroniknet.de brachte mir eine fundamentale Erkenntnis: Die Multicore-Programmierung findet offensichtlich noch in einem zu geringen Ausmaß statt, da es nicht an Entwicklertools fehlt, sondern an Entwicklern, die damit umgehen können. Diese Theorie stellt zumindest Professor Klaus Kißig von der FH Kiel auf. Seine Kernthese dürfte die Ohren diverser Kollegen und Dekane anderer Bildungseinrichtungen zum Klingeln bringen:
Das Problem ist eher, dass es zu wenige Leute gibt, die die Kenntnisse haben, um diese Compiler effektiv anzuwenden und die Hardware optimal ausnutzen können.
Mit „diese Compiler“ meint er unter anderem Intel-Compiler, die ständig weiterentwickelt werden. Aber auch den Einsatz von OpenMP in Verbindung mit Standard-Compilern sieht er in diesem Kontext als großen Vorteil.
Das bedeutet also, dass es vor allem bei der Ausbildung hakt, da es die jeweiligen Einrichtungen bis dato offensichtlich noch nicht geschafft haben, neue Techniken wie Multicore-Systeme in den Vorlesungsplan zu integrieren.
Apple Mac OS X 10.6 mit hohem Multicore-Potenzial
John Hubbard scheint ein ziemlich kluger Kopf zu sein. Denn erstens beschäftigt er sich bei Apple als Director of Unix Technologies mit sehr komplexen und ernsthaften Dingen. Und zweitens hat er Mitte November auf einer Konferenz in San Diego bemerkenswerte Dinge über Intel und Multicore gesagt. Beispiele gefällig?
Forget everything you thought you knew about multi-threaded programming (and, as it turns out, most developers didn’t know much anyway).
The kernel is the only one who really knows the right mix of cores and power states to use at any given time – this can’t be a pure app-driven decision.
We need new APIs and mechanisms for dealing with this incoming meteor.
Wie gut, dass sich Intel über Letzteres bereits Gedanken macht und Tools wie Intel TBB und Intel Parallel Studio bietet, mit deren Hilfe die Multicore-Programmierung deutlich erleichtert werden kann.
Weniger schlau während seines Vortrags war allerdings die Folie Nummer 5, auf der er (ganz inoffiziell natürlich) den Erscheinungszeitraum der nächsten OS-X-Version 10.6 aka Snow Leopard bekannt gegeben hat, nämlich das erste Quartal 2009. Anfang Juni während der Apple-Entwicklerkonferenz WWDC’08 war noch von ungefähr einem Jahr die Rede, bis Mac OS X 10.6 in die Läden kommt. Tja, dumm gelaufen!
Und was hat das alles mit Multicore-Programmierung zu tun? Nun, in der nächsten Version des Apple-Betriebssystems wird ganz viel Multicore-Unterstützung stecken. Leider gibt Apple noch nichts Konkretes raus (und John leider auch nicht), aber einige grundsätzliche Dinge sind heute schon klar:
