Ja, ich weiß, lang ist es her, dass ich den ersten Teil geschrieben habe aber nun (nach nur 5 Monaten) gehts endlich weiter, und diesmal wirds neben der Theorie auch Code geben!

Wie ihr seht habe ich den Titel etwas abgeändert nun tauchen da drei neue Buchstaben auf die ihr (vielleicht) noch nie gehört habt, diese stehen für Task Parallel Library. Wie der Name es schon sagt, ist es eine Library die es uns ermöglicht parallel zu programmieren, aber dazu später mehr!

Machen wir erstmal mit ein wenig Theorie weiter. Im ersten Teil haben wir erfahren, dass es nicht automatisch heißt, dass ein Programm schneller wird, wenn man viele Prozessoren im Rechner verbaut hat, und diesen Gedanken möchte ich in dem zweiten Teil noch etwas fortführen.

Dazu möchte ich ein Beispiel geben. Nehmen wir an wir haben eine Funktion geschrieben, in der eine FOR-Schleife vorkommt die viele Berechnungen anstellt und die Ergebnisse in ein Array Speichert zb so:

Error: Not Found
The requested URL / was not found on this server.

Zugegeben, auf den ersten Blick sieht das ganze verwirrend aus, da der Kopf der Schleife sich geändert hat. Aber auf den zweiten Blick erkennt man viel wieder. So beginnt die Schleife ebenfalls mit dem Startwert, gefolgt von der Abbruchbedingung. Nun kommt das neue, denn die TPL verwendet hier die so genannten Lambda Ausdrücke, die mit C# 3.0 Einzug erhielten. So ist es nun möglich ganze Codeblöcke in Parameter Felder zu setzen und vieles mehr.

Aber man langsam, man beginnt hier mit der Initialisierung der benötigten Variablen in diesem Fall nur eine namens „i“, die Initialisierung erfolgt Typenlos in runden Klammern mit dem Pfeil dahinter wird der dazugehörige Codeblock initiiert (Anonyme Methoden). (ihr könnt die Variablen auch Typisieren, wenn ihr aber keinen Typ angibt wird er automatisch bestimmt!)

Der Inhalt der Schleife bleibt hierbei aber exakt der gleiche, praktisch oder? Aber was passiert nun genau? Naja einfach ausgedrückt wird der Block in viele einzelne Teile zerbrochen die in eigenen Threads dann über die verfügbaren CPU-Kerne verteilt werden. Schließlich werden die Ergebnisse wieder zusammengetragen!

Bevor wir nun hingehen und die neue Schleife testen will ich euch noch was zeigen. Auf dem Folgenden Screenshot sieht man die CPU-Auslastung während unsere erste sequentielle Schleife läuft:

Bild 2: CPU-Auslastung während sequentieller Berechnung

Wie man ganz klar erkennen kann werden beide Kerne belastet! Wie kann das sein? Das Programm ist doch sequentiell! Die Erklärung ist relativ simpel, denn das System (hier Windows 7) erkennt auch, dass da ein Programm einen Kern überlastet und verteilt die Last automatisch auf andere Kerne. Ok, und warum soll ich mir nun die mühe machen und parallel programmieren wenn das System das doch auch so für mich macht?

Ganz einfach, weil das System es schlecht macht. Hier kann man es nicht erkennen, da der PC nur 2 Kerne hat. Wenn man mehr Kerne hätte würde man erkennen, dass das System, zwar versucht einen Kern zu entlasten und die Arbeit zu verteilen, aber es bezieht nur 1, vielleicht 2 weitere kerne in die Arbeit mit ein, alle anderen dürfen weiter „karten spielen“ und auf Arbeit warten. Wenn wir aber unser Programm parallel gestalten, werden alle verfügbaren Kerne ausgenutzt!

Ok, dann wollen wir mal unsere überarbeitete parallel laufende Schleife mal anschmeißen:

Bild 3: Parallel laufende Schleife

Ahja, wie man sieht konnte unsere neue Schleife die Werte in fast der halben Zeit berechnen. Das ist eine enorme Steigerung! Schauen wir uns auch nochmal die CPU-Auslastung an:

Bild 4: Steile Berge

Man erkennt sofort, dass die CPU hier sehr viel effizienter genutzt wird, die Auslastung steigt kurz bis an das Maximum an und geht danach direkt wieder runter! Vergleicht man das Bild mit dem Sequentiellen sieht man auch, dass beide Kerne fast gleichstark und auch durchgängig belastet werden. Die last wird perfekt auf die verschiedenen Kerne verteilt!

Ruft man beide Funktionen hintereinander zur Laufzeit auf, wird der Unterschied noch besser sichtbar:

Bild 5: 100% Schneller

Der Unterschied ist gewaltig, man würde den Unterschied noch mehr spüren, wenn man eine Schleife mit einem Größerem Body testen würde, aber das könnt ihr dann ja mal selber irgendwann üben.

In bild 5 sieht man die Ergebnisse der Berechnung auf einem Windows 7 32 Bit Rechner mit einem Core2Duo mit 2,4 gHz. Schauen wir uns doch mal an, wie die Zahlen abweichen wenn wir ein System haben dass ein paar mehr Kerne hat und im 64 Bit Modus läuft:

Bild 6: Unglaublich oder?

Hier sieht man es nochmal ganz deutlich wie überlegen die parallel programmierte Schleife der sequentiellen ist. So sieht die CPU Verteilung aus auf einem 64 Bit System mit 16 Kernen:

Bild 7: Gegenüberstellung (Zum vergrößern klicken)

Wie man sieht beansprucht die sequentielle Schleife nur 4 der Prozessoren, und das nicht mal ganz. Die parallele Schleife dagegen hat 15 der 16 Kerne belastet und ist dem entsprechend 10 mal schneller fertig geworden!

Zum Schluss will ich noch eine kleine Schwäche der Parallelen Variante (wenn man sie Schwäche nennen mag) zeigen. Ich habe hier ganz bewusst eine Schleife genommen, die 10 Millionen mal ausgeführt wird, denn wenn die Schleife kleiner wird, hat man mit der Parallelen Schleife keinen Vorteil mehr!

Die Erklärung dafür habe ich zu Beginn dieses Artikels gegeben, denn die Thread Erzeugung dauert einfach viel zu lange! So sieht man hier den Ablauf der selben Schleife mit 100.000, 10.000 und 1000 Durchgängen:

Bild 8: Man muss vorher abwägen

Man muss sich unbedingt vorher Gedanken machen, ob es sich lohnt einen Prozess zu parallelisieren.

In dem Nächten Teil, der (ich hoffe) bald kommt werde ich euch dann noch ein paar weitere Gefahren zeigen, und auch Methoden wie man die Parallelisierung noch ein wenig beschleunigen kann, sowie auch weitere Beispiele mit anderen Schleifen und ganzen Codeblöcken!

Ich hoffe der Artikel hat euch gefallen und freue mich auf euer Feedback!

Die Demoanwendung gibts hier:

.

.