Sämtliche Beiträge des Monats Februar 2009
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.
Thread Profiler: Parallelisierte Anwendungen grafisch testen
Über Tools für die parallele Programmierung habe ich mich hier schon ausgiebig ausgelassen: Concurrency Checker, Thread Checker, VTune Performance Analyzer, Intel TBB, Multicore-Bibliotheken, Parallel Studio und andere Werkzeuge sind Teil des Software Dev Blogs. Was auf der Liste allerdings immer noch fehlt ist der Thread Profiler. Bis heute!
Der Thread Profiler ist ein Analysetool, mit dem sich Schwachstellen in parallelisierten Anwendungen grafisch darstellen lassen. Hierzu ist kein Quellcode notwendig, da der Thread Profiler das ausführbare Programm, also die Exe-Datei, untersucht. Dabei können folgende Dinge aufgespürt werden:
- Unter- und überbeschäftigte Ressourcen werden grafisch dargestellt. Damit kann der Programmierer sofort sehen, an welchen Stellen das Programm auf der Multicore-Plattform optimal, ein wenig oder gar nicht skaliert.
- Der Programmablauf wird visualisiert. Es lässt sich auf diesem Weg also feststellen, wo die kritischen Pfade sind, welche Abschnitte der Anwendung sequenziell ausgeführt werden und an welchen Stellen die einzelnen Threads aktiv oder inaktiv waren bzw. wann sie warten mussten.
Concurrency Checker: Wie parallel ist parallel?
Anfang Februar habe ich schon mal darüber berichtet: Mit dem kostenlosen Intel-Tool Concurrency Checker kann man ohne größere Mühen herausfinden, ob und in welchem Umfang eine parallelisierte Anwendung skaliert. Hierfür beherrscht das Tool einige wichtige Dinge:
- Es stellt die Anzahl der vorhandenen CPU-Ressourcen fest, also Prozessoren und Prozessorkerne (und sogar virtuelle CPUs).
- Es stellt fest, wie viele Threads jeweils parallel ausgeführt werden und wie lange dies insgesamt dauert.
- Es berechnet den prozentualen Anteil des parallelisierten Quellcodes.
Der Concurrency Checker kann aber noch mehr: So stellt er fest, ob die Multithread-Anwendung anhand der vorhandenen Prozessorkerne skaliert, diese also vollständig ausnutzt. Dies geschieht übrigens zur Laufzeit der Software. Schön an dem Tool ist aber auch die Tatsache, dass es nicht erst aufwendig installiert werden muss und damit sofort zur Verfügung steht. Und zwar mittels einer grafischen Bedieneroberfläche oder im simplen Zeileneditormodus.
Das Werkzeug kann aber auch auch zu Vergleichszwecken eingesetzt werden: Zunächst lässt man sein serielles Programm einmal mit dem Tool durchlaufen, um so die benötigte Laufzeit herauszufinden. Nach der Parallelisierung geschieht das Ganze noch einmal, womit man einen guten Indikator dafür erhält, wie gut das Multithreaden der Anwendung geklappt hat.
Was der Concurrency Checker allerdings nicht kann ist zweierlei: Es gibt keine Hinweise darauf, welche Stellen der sequenziell programmierten Anwendung das höchste Parallelisierungspotenzial aufweisen. Und zum anderen lassen sich Hotspots und andere Probleme der parallelisierten Software mit dem Tool nicht herausfinden. Wie gut aber, dass es hierfür Werkzeuge wie den VTune Performance Analyzer und den Thread Checker gibt.
Ach ja: Den Concurrency Checker bekommt ihr auf dieser Webseite, und das gratis!
Workshop: parallel Programmieren mit OpenMP
Über OpenMP habe ich hier schon des öfteren gebloggt, aber noch nie so wirklich im Detail. Das wird sich heute schlagartig ändern, denn ein lieber Kollege (danke, Edmund!) hat mir am Wochenende einen sehr anschaulichen Artikel zukommen lassen, der mir als Grundlage für das heutige Posting dient. Den kompletten Beitrag samt Programmierbeispiel anhand der Kreiszahl Pi gibt es als PDF zum Download.
Zunächst einmal: OpenMP liegt in der Version 3.0 vor und stellt eine standardisierte Programmierungsmethode dar. In Sachen Komplexität bewegt sie sich zwischen den herkömmlichen Threads – also API-Threads, PThreads oder WinThreads – und den höher entwickelten Intel TBB oder der geplanten Parallel Pattern Library (PPL), die von Microsoft kommen wird.
Daraus ergeben sich zwei wesentliche Aspekte: OpenMP ist weitaus einfacher zu verstehen, zu implementieren und zu testen als die Low-Level-Threads, bei denen sich der Programmierer um viele Dinge selbst kümmern muss, was das Ganze natürlich extrem fehleranfällig macht.
Die Kehrseite von OpenMP ergibt sich aus der geringeren Komplexität: Nicht alle Programmieraufgaben lassen sich mit OpenMP erledigen, was den Entwickler natürlich ein wenig einschränkt. OpenMP versteht sich vor allem sehr gut auf das Parallelisieren von rechenintensiven Schleifenkonstrukten.
Parallel-Bibliotheken helfen bei der Software-Entwicklung
Ende Januar habe ich auf Basis eines Vortrags von Walter Tichy, Uniprofessor in Karlsruhe, 12 Thesen und 12 passende Antithesen zum Thema Multicore-Programmierung aufgestellt. These Nummer 12 beschäftigt sich mit Professor Tichys Aussage, es gäbe für bestimmte, immer wiederkehrende Aufgaben der Parallelprogrammierung noch nicht die passenden Tools auf dem Markt.
Schon seinerzeit habe ich dagegen gesprochen, da sehr wohl Software-Werkzeuge existieren wie die Integrated Performance Primitives (IPP), die vor allem Entwickler von Multimedia-Software bei ihrer Arbeit unterstützen sollen. So basieren zahlreiche MP3- und AAC-Encoder/-Decoder auf Teilen der IPP-Bibliotheken, in denen übrigens viele Mannjahre Entwicklungsarbeit stecken.
Mit den IPP lassen sich einzelne Funktionen für das Encoden von Audio- und Videostreams mehr oder weniger per Drag & Drop für eigene Anwendungen nutzen, die dann bestimmte Aufgaben hochparallelisiert ausführen – ohne dass der Programmierer sich darüber Gedanken machen muss, wie dies funktioniert. Bekannte Beispiele hierfür sind H.264-, MPEG-4- und AAC-basierte Encoder.
Aber auch im medizinischen Bereich für die rechenintensive Auswertung von Ultraschallbildern kommen IPP-Bibliotheken zum Einsatz. Damit lassen sich hochkomplexe 3D-Bilder deutlich schneller analysieren, da die vorhandenen Prozessoren simultan die Berechnungen durchführen können. Somit spart der Einsatz der IPP im günstigsten Fall drei bis vier Mannjahre Entwicklungszeit, die das Programmieren solcher Parallel-Bibliotheken resp. der zugehörigen Anwendung in Anspruch nähmen.
Parallel-Studio-Serie (4): mehr Infos zum Parallel Amplifier
Mit dem vierten und letzten Teil endet unsere kleine Serie rund ums Parallel Studio. Thema des heutigen Blogeintrags: Parallel Amplifier. (Hier geht’s zu den Teilen eins, zwei und drei).
Wie ich ja schon berichtet habe, sucht der Parallel Amplifier nach Optimierungspotenzial in Multithread-Anwendungen. Für eine optimale Performance also. Hierfür leistet das Tuningtool eine ganze Menge:
Aufspüren von Hotspots: An welchen Stellen verbrät die Anwendung besonders viel Zeit und was kann ich dagegen tun? Hierzu werden die kritischen Bereiche grafisch dargestellt und können so schneller identifiziert werden. Zudem liefern die Stack-Aufrufe wichtige Infos über das Laufzeitverhalten der Anwendung.
Parallelität verbessern: Wo klappt es mit der Parallelisierung noch nicht so gut und welche Quellcode-Abschnitte könnte man noch weiter simultan schalten? Um diese Fragen beantworten zu können, erhält der Anwendungsentwickler grafisch aufbereitete Hinweise darauf, welche Programmabschnitte die vorhandenen CPU-Ressourcen über- bzw. unterbeanspruchen. Genau an diesen Stellen lässt sich dann der Quellcode tunen.
Wartezeiten finden: Wo muss die Anwendung zu lange warten, weil bestimmte Abhängigkeiten existieren? Wie kann ich diese Hotspots identifizieren und möglichst auflösen? Auch hierfür stellt der Parallel Amplifier die betreffenden Quellcode-Abschnitte grafisch dar und zeigt in Balkenform die Auslastung der Prozessoren an. So lassen sich Idle-Zustände relativ einfach herausfinden.
Eine weitere praktische Eigenschaft des Parallel Amplifier ist dessen Transparenz in Sachen Laufzeitverhalten. So lässt sich jede Funktion, jeder Callaufruf und jede Prozedur bis auf jede einzelne Quellcode-Zeile herunterbrechen und analysieren. Das gibt dem Programmierer ein gutes Gefühl dafür, wo es klemmt und wo er noch mehr machen muss.
Und es lassen sich mehrere Testläufte aufzeichnen und die Ergebnisse miteinander vergleichen. Auch das sorgt im Problemfall für zusätzliche Hinsweise darauf, dass die parallelisierte Anwendung weiter optimiert werden muss – oder sich gar Fehler eingeschlichen haben.
Parallel-Studio-Serie (3): mehr Infos zum Parallel Inspector
In den ersten beiden Teilen der Serie “Mit Parallel Studio Anwendungen multithreaden” ging es um die drei aktuellen Komponenten des Entwicklungstools: Parallel Composer, Parallel Inspector und Parallel Amplifier. Heute werde ich mir den Inspector noch mal ein wenig genauer ansehen.
Im Parallel Inspector steckt ein erprobtes Tool, und zwar der Thread Checker. Daher ist der Inspector primär für das Auffinden von Fehlern zuständig, die sich in Multithread-Code eingeschlichen haben. Um dies alles erledigen zu können, beherrscht das Debug-Tool eine Menge Dinge:
- Es entdeckt Speicherprobleme und -fehler, findet also fehlerhafte Speicherzuweisungen und korrupte Speicherdaten, die möglicherweise zu schwerwiegenden Fehlern während der Laufzeit führen würden.
- Die bekannten Threading-Fehler wie Deadlocks und Race Conditions spürt der Inspector zuverlässig auf. Gerade diese nicht-deterministischen Laufzeitprobleme können mit herkömmlichen Debug-Tools kaum oder nur mit größtem Aufwand gefunden werden.
- Der gesamte Multithread-Code wird nach Fehlern durchforstet. Vor allem die zur Laufzeit auftretenden Probleme erkennt der Inspector und führt den Programmierer direkt zu der betroffenenen Stelle. Dabei wird auch der zugehörige Call Stack angezeigt und die betroffenen Speicherstellen. Warnhinweise und Fehlermarkierungen helfen dabei, die aufgetretenen Probleme besser und schneller zu verstehen.
- Das alles findet dank der Integration in Visual Studio unter einer einheitlichen und vertrauten Entwicklerumgebung statt. Damit lassen sich Fehler schneller erkennen, verifizieren und eliminieren. Das Gute daran: Es muss nicht jedesmal ein “Rebuild” des Quellcodes durchgeführt werden.
Serie: Mit Parallel Studio Anwendungen multithreaden (2)
Am Freitag habe ich eine kleine Serie um Parallel Studio gestartet. Im ersten Teil geht es um den Parallel Composer, mit dessen Hilfe paralleler Quellcode erzeugt werden kann. Das heutige zweite Kapitel handelt von den Komponenten Parallel Inspector und Parallel Amplifier.
Mit dem Parallel Inspector lassen sich Multithread-Anwendungen in vielfältiger Weise debuggen. Es geht allerdings um weit mehr als das bloße Aufspüren von Quellcode-Fehlern:
- Es spielt keine Rolle, welche Programmiermethode eingesetzt wird. Parallel Inspector unterstützt nämlich OpenMP (besser: er basiert darauf), kommt aber auch mit Intel TBB und Windows Threads klar.
- Fehler wie Dead Locks und Race Conditions werden zur Laufzeit gefunden, bevor sie der Kunde findet.
- Das Laufzeitverhalten wird vollständig aufgezeichnet, um so nachträglich und detailliert mögliche Fehler und Probleme innerhalb der parallelisierten Anwendung zu identifizieren.
- Im Gegensatz zu anderen Testtools können schwer auffindbare, nicht-deterministische Fehler mit Parallel Inspector aufgespürt werden.
- Pate des Parallel-Debuggers ist der Thread Checker. Damit bekommt man ein zuverlässiges, weil erprobtes Tool an die Hand zum Debuggen seiner Anwendungen.
- Parallel Inspector fügt sich nahtlos in Visual Studio ein.
Serie: Mit Parallel Studio Anwendungen multithreaden (1)
Heute beginnt auf dem Software Dev Blog die Serie “Mit Parallel Studio Anwendungen multithreaden”. In den geplanten Folgen geht es im Einzelnen um die Komponenten Parallel Composer, Parallel Inspector und Parallel Amplifier.
Der erste Teil handelt vom Parallel Composer, der mit einer Reihe nützlicher Tools die Parallelisierung serieller Anwendungen erleichtern soll. Hierfür bietet er
- vereinfachte Multithread-Funktionen, die allesamt auf OpenMP 3.0 basieren und als solche im Hintergrund eingesetzt werden
- Vektorisierungspragmas in Kombination mit den SSE2-/SSE3-/SSSE3- und SSE4-Befehlen
- einfache Integration in die Entwicklungsumgebung von Microsoft Visual Studio
- Intel Parallel Debugger Extensions als Plugin für Visual Studio
- Lambda-Funktionen (nur C++) für den vereinfachten Austausch mit Intel TBB
- Unterstützung der Vektorschreibweise (arr[i])
- automatische Parallelisierung von Quellcode
- Diagnosetools, die beim Entwickeln von Multithread-Quellcode helfen
- zahlreiche Multithread-Beispiele mit dem entsprechenden Quellcode
Und am Montag gibt es dann mehr Infos zu Parallel Inspector und Parallel Amplifier ein anschauliches Beispiel, Infos zu OpenMP 3.0 und einiges mehr. Und die zusätzlichen Infos zu OpenMP und Co. gibt es am Dienstag …
Online-Seminare rund um Intel Parallel Studio
Kaum ist das Entwicklertool für parallele Programmierung, Intel Parallel Studio, in die Beta-Phase eingestiegen, hagelt es massenhaft Online-Webinars zu diesem Thema. Wer sich also für Parallel Studio im Detail interessiert, sollte sich für die Internetschulungen anmelden, die Intel gratis anbietet. Die Termine und Themen sehen wie folgt aus:
10. März 2009: Go-Parallelism! Ease the Onramp for C/C++ Windows Development Hier erfährt man alles Wissenswerte über Parallel Studio aus erster Hand von einem der Parallelexperten aus dem Hause Intel, nämlich James Reinders persönlich. Dieses Webinar ist ein erster, guter Überblick für alle angehenden Parallelentwickler.
17. März 2009: Solve Parallelism with Intel Parallel Studio In seinem Webinar weiht Joe Wolf künftige Multithread-Entwickler in das mathematische Damenproblem (N-Queens) ein und zeigt, wie es sich mithilfe von Parallel Studio lösen lässt. Hierzu sollte man das Entwicklertool am besten schon auf seinem Rechner installiert haben, um die notwendigen Programmierschritte während der Session durchführen zu können.
31. März 2009: Parallel Implementation Methods with Intel Parallel Composer Intel-Mann Ganesh Rao wird eine Menge über Programmiermethoden wie OpenMP und Intel TBB erzählen, die sich in Parallel Studio einbinden und nutzen lassen. Es geht aber auch um multithread-optimierte Bibliotheken wie Intel IPP und Debugger-Tools wie Intel Parallel Debugger Extension und den Parallel Inspector, der ja Teil von Parallel Studio ist.
Multicore-Fähigkeiten mit Spezialtool herausfinden
Im bayerischen Pilsting-Großköllnbach kennt man sich ziemlich gut aus mit der Archivierung von relationalen Datenbanken. Denn in Pilsting-Großköllnbach sitzt die Software-Schmiede CSP GmbH und Co. KG, die das Archivierungstool Chronos entwickelt hat. Diese Anwendung lagert nicht permanent benötigte Daten in ein Langzeitarchiv aus, um so die vorhandenen Datenbankserver kontinuierlich zu entlasten.
Das Extrahieren dieser Daten geschieht in Echtzeit, also während des laufenden Betriebs. Um eine möglichst reibungslose Archivierung zu garantieren, hat sich die CSP schon sehr früh auf das Multithreaden ihrer Anwendung konzentriert.
Das gesamte Konzept ist also auf parallele Datenverarbeitung ausgelegt. Es findet sogar eine doppelte Parallelisierung statt: Es kommt ein Mini-Cluster zum Einsatz, in dem einzelne Server bestimmte Aufgaben übernehmen. Und innerhalb dieser Server gibt es eine hohe Multithreading-Kultur, die eine skalierende Ausführung der Anwendung sicherstellt.
Chronos ist übrigens vollständig in Java programmiert und findet innerhalb der Java Runtime Environment statt, die standardmäßig mit Java-Threads auskommt. Auf diesem Weg können Java-Anwendungen mithilfe bestimmter Bibliotheken und Klassen parallelisiert werden. Für die komplette Verwaltung sämtlicher Threads hat CSP übrigens einen eigenen Threadmanager entwickelt, der im Hintergrund analog zu den Threading Building Blocks die einzelnen Tasks auf die vorhandenen Prozessoren und Threads verteilt. Für eine bestmögliche Auslastung der Ressourcen.
Wieso können sich die Entwickler von CSP aber so sicher sein, dass Chronos wirklich optimal auf Intel Multicore-Plattformen skaliert? Nun, um das herauszufinden, besorgte man sich in Pilsting-Großköllnbach das kostenlose Tool Concurrency Checker, mit dessen Hilfe festgestellt werden kann, ob eine Anwendung effizient auf Intel Multicore-Plattformen läuft.
Und die Entwickler der CSP GmbH waren ziemlich schnell davon überzeugt, dass der Concurrency Checker das richtige Tool für ihre Zwecke ist. Denn sie waren sehr zufrieden mit der Bedienbarkeit des Programms, da sie für einen ausführlichen Multicore-Test gerade mal einen halben Tag investieren mussten. Danach war den CSP-Programmierern klar, dass sich der Concurrency Checker für ihre Zwecke optimal einsetzen lässt. Und dass Chronos auch das hält, was es verspricht: eine optimale Ausnutzung der vorhandenen Systemressourcen, sprich der Prozessorkerne und Threads.
Interview: Visual Studio 2010 und seine Multicore-Fähigkeiten
Während der OOP 2009 gab es die Möglichkeit, mit Microsoft zusammenzusitzen und ein wenig über Visual Studio 2010 und das zugehörige .NET Framework 4.0 zu plaudern. So der Plan! Leider kam es anders, was dazu führte, dass ich am vorigen Mittwoch via Festnetz mit einem der Technikgurus, Dariusz Parys, über diverse Aspekte der Parallelprogrammierung mithilfe des .NET-Framework in der Version 4.0 sprach. Und das ist dabei herausgekommen.
Wie unterstützt das .NET Framework 4.0 die parallele Programmierung?
Hierfür gibt es diverse Komponenten. Es wird sowohl für den Bereich “Managed Applications” – also C# und Konsorten – als auch für native Programmiersprachen (Fortran, C++ etc.) Bibliotheken und ähnliche Dinge geben. Für beide Programmiermodelle wurde die Concurrency Runtime entsprechend aufgebohrt.
Für die .NET-Entwickler gibt es dann zwei neue Modelle, und zwar die Task Parallel Library (TPL) und PLING. Mit der TPL lassen sich Aufgaben abstrahieren, was unter der Oberfläche und mithilfe der Concurrency Runtime zu Threads führt, um deren Verteilung auf die einzelnen Prozessorkerne sich der Entwickler nicht mehr kümmern muss. PLINQ stellt eine parallelisierte Erweiterung von LINQ dar. Und LINQ wiederum ist “eine Komponente von Microsofts .NET-Framework, mit der SQL-, XLink- und XQuery-Anfragen direkt in .NET-Programmiersprachen wie C# 3.0 oder VB.Net 9.0 als Code statt als String eingebunden werden können” (Quelle: Wikipedia).
Aber auch bei den nativen Sprachen gibt es neue Ansätze bezüglich der Concurrency Runtime: Dies ist zum einen die Parallel Pattern Library, die sich mit den Intel Threading Building Blocks vergleichen lässt. Zum anderen bietet Visual Studio 2010 eine Agent Library für C++ und Co, die bestimmte Aufgaben verwalten und ausführen kann.
Was sagen Sie Entwicklern, wenn Sie mit ihnen über die parallele Programmierung reden?
Das hängt davon ab, mit wem ich spreche. Entwickler, die sich zum Beispiel schon länger mit serviceorientierten Anwendungen beschäftigen, in denen separate Aufgaben durch Dienste erledigt werden, verstehen das Konzept der parallelen Programmierung oft schneller als Programmierer, die nur die rein serielle Entwicklung kennen. Wichtig dabei ist die Erkenntnis, dass es in den meisten Anwendungen Programmteile gibt, die man loslösen kann von der restlichen Programmlogik. Ein Beispiel hierfür ist die parallele Speicherung von Daten.
Intel Parallel Studio ab sofort als Beta erhältlich
Seit Ende November gibt es eine Light-Variante des Intel Parallel Studio, nämlich den Parallel Composer als Beta, die man sich als interessierter Entwickler auf seinen Rechner ziehen kann, um damit schon mal ein wenig Paralleles Programmieren zu üben.
Tja, und ab sofort steht das komplette Paket Parallel Studio zum Beta-Testen bereit. Das Tool besteht aus den drei Programmteilen Composer, Inspector und Amplifier. Was der Composer kann, muss ich nicht noch mal erklären. Der Inspector untersucht ähnlich wie der Thread Checker parallelisierten Code auf mögliche Fehler hin. Das sind vor allem schlimme Dinge wie Deadlocks und Race Conditions, die sich meist erst zur Laufzeit erkennen geben und mit herkömmlichen Testmethoden oder Debuggern kaum aufspürbar sind.
Der Amplifier schließlich ist für das Finetuning der parallelisierten Anwendung zuständig. So findet er beispielsweise selbstständig seriellen Quellcode, der noch parallelisiert werden könnte. Aber auch Engstellen im Programmablauf, die sich durch die Parallelisierung ergeben haben, stöbert der Amplifier auf.
Um am Betaprogramm von Parallel Studio teilnehmen zu können, sollte man Microsoft Visual Studio 2005 oder 2008 einsetzen (außer Express), in C oder C++ programmieren, und das unter Windows XP, Vista, Windows Server 2003 oder 2008. Mac- und Linux-Anwender bleiben leider (erst mal) außen vor.
Und hier geht es zur Teilnahme am Betaprogramm (für die Anmeldung ist lediglich eine gültige E-Mail-Adresse erforderlich). Viel Spaß beim Testen!
Bücher und Webinar an Software-Entwickler zu verschenken
Über das Intel Software Partner Program (Intel SPP) hatte ich Ende Oktober ausführlich berichtet. Kurz gefasst geht es um die Möglichkeit, als Software-Entwickler von Intel in Sachen Programmierung unterstützt zu werden. Das reicht von vergünstigten Einkaufskonditionen für Software-Tools bis hin zur Möglichkeit, an professionell erstelltes Marketingmaterial heranzukommen.
Um am Intel SPP teilnehmen zu können, muss man sich natürlich erst mal registrieren. Logisch. Um dies ein wenig schmackhafter zu machen, verschenkt Intel derzeit 50 Exemplare des Buchs Multi-Core Programming, das ich übrigens auf meinem Schreibtisch liegen habe. Dabei handelt es um einen wirklich gelungenen Einstieg in das Thema und eine nützliche Wissensdatenbank für alle Entwickler. Also, ran an den Speck!
Apropos Speck: Software-Entwicklung für den relativ neuen Intel-Prozessor Core i7 ist noch kein echtes Mainstream-Thema. Zwar gibt es schon eine ganze Weile ein eigenes SDK, aber Experten auf diesem Terrain sind noch eher rar. Um diesen Umstand zu verbessern, bietet Intel am nächsten Dienstag (10. Februar, 17 Uhr MEZ) ein 60-minütiges Webinar genau zu diesem Thema an. Der Titel:
Create Applications with Superior Performance and Energy-Efficiency: An Introduction to the Software Development Kit for the new Intel Core i7 Platform
Das ist doch genau das Richtige für angehende Multicore-Entwickler, oder?! Und wie gesagt: Davon gibt es nicht so wahsinnig viele. Ach ja: Um an diesem internetbasierten Training teilnehmen zu können, muss man sich für das Intel Black Belt-Programm anmelden. Das ist allerdings ein Klacks – verglichen mit Multithreading für Multicore-Prozessoren.
Multicore-Programmierung im .NET-Umfeld – Teil 3
Nach den Teilen eins und zwei folgt heute der dritte Abschnitt unserer Mini-Serie “Multicore-Programmierung im .NET-Umfeld”. Es geht um Tasks und Futures, um das Parallelisieren von Methoden, um parallele Schleifen, um einen Taskmanager und um PLINQ.
Tasks sind die zentralen Elemente der Parallel Extensions, also dedizierte Aufgaben, Funktionen, Schleifenkonstrukte oder ähnliche Dinge. Eine Task führt stets eine Funktion oder ein anderes Konstrukt innerhalb eines Threads aus, um so eine optimale Ausnutzung der Systemressourcen zu erzielen.
Das Besondere daran sind die Call-Back-Funktionen, die es ermöglichen, bestimmte Dinge zu übergeben, die in einem separaten Thread ausgeführt werden sollen. Mithilfe der Tasks müssen Anwendungsprogrammierer also nicht mehr in Threads denken, da diese von den .NET-Tools automatisch erzeugt, verwaltet und auf die vorhandenen Ressourcen verteilt werden.
Daneben gibt es Futures, also Tasks mit Rückgabewerten. Solch ein Future-Konstrukt führt beispielsweise in einem eigenen Task eine Funktion aus, deren Ergebnis an das Hauptprogramm übergeben wird, das währenddessen weiterrechnen kann. Zwar muss das Programm an einer bestimmten Stelle auf das Ergebnis warten, kann aber trotzdem parallel andere Aufgaben ausführen. Eine weitere simultane Ausführungsoption ist die Methode Parallel_Invoke(), die einen ganzen Satz von Methoden zugleich abarbeiten kann, sofern diese voneinander unabhängig sind.
