meisse - Sa 11.06.11 13:12
Titel: Normale Threads vs Task Parallel Libary

---

Hallo zusammen

Wie ich gelesen habe ist die TPL (Task Parallel Library) seit der .NET 4.0 Version erhältlich.
Diese sollte das parallele programmieren von Threads vereinfachen und zu dem gleich auch den
Prozessor optimal ausnutzen (Dual Core, Quad Core etc.).
Da ich noch meine Programme mit .NET 3.5 kompiliere, kann ich diese Library noch nicht verwenden.
Ich habe mich jetzt gefragt, wenn ich mehrere Threads erstelle (ThreadStart thread = new ThreadStart(..))
werden diese dann auch von Betriebsystem optimal auf die Prozessorkerne verteilt? Oder eben wird
das erst optimal wenn ich diese TPL Library verwende?
Zum beispiel gerade bei FOR-Schlaufen kann die TPL Libary diese automatisch parallelisieren was einen wesentlichen
Geschwindigkeitsvorteil ergibt. Dies kann ich ja mit der normalen THread-Technik nicht erreichen oder etwa doch?
Kann mir da jemand ein weniger weiterhelfen?

Mit freundlichen Grüssen

Christian S. - Sa 11.06.11 13:33

---

Hallo!

Der Vorteil, dass die TPL die Verwaltung übernimmt, ist nicht zu unterschätzen. Damit musst Du Dich nämlich nicht drum kümmern, was die optimale Anzahl an Threads ist. Ich schreibe in letzter Zeit an einem Programm, welches ich auf einem Dualcore entwickle und auf einem Hexacore dann rechnen lasse. Da unterscheidet sich ja dann schon die optimale Anzahl an Threads. Das kann man natürlich auch selber ausknobeln, aber praktischer ist es, das die TPL machen zu lassen.

Auffällig wird das, wenn man Schleifen parallelisiert. Will man das selber machen, würde man den von der Schleife abgedeckten Bereich an Indizizes in so viele Teilbereiche unterteilen, wie es Prozessoren gibt und jeden der Teilbereiche in einem eigenen Thread rechnen lassen. Das wird dann nicht nur sehr viel schwerer lesbar, sondern man muss sich auch selber drum kümmern, dass der Hauptthread wartet bis die anderen Threads fertig sind, und vielleicht auch schauen, dass wen ein Thread schneller fertig ist als der andere, der noch ein paar Aufgaben übernehmen kann. Insbesondere der letzte Teil ist nicht trivial.

Das sieht in der TPL dann einfacher aus. Aus

wird

Und Du bist alle diese Sorgen los :-) Und es skaliert meiner Erfahrung nach wirklich hervorragend!

Als Fazit kann man wohl sagen: Die TPL nimmt Dir Arbeit ab, macht die Arbeit wahrscheinlich besser, als man selber das mit annehmbaren Aufwand kann und führt zu besser lesbarem Code. Was will man mehr ;-)

Grüße
Christian

Th69 - Sa 11.06.11 14:15

---

Hallo,

ich kann da Christian nur zustimmen. Die TPL ist wirklich sehr einfach zu benutzen und nimmt einem selber sehr viel Arbeit ab, insbesondere der Aspekt der Skalierbarkeit ist hervorzuheben (wie Christian ja auch schon als Beispiel DualCore->HexCore gezeigt hat).
Mit klassischer Thread-Programmierung müßte man ja auf jedem unterschiedlichen MultiCore-System testen, um bestmögliche Performance zu erzielen - und dies übernimmt nun die TPL im Hintergrund. Und im Einzelfall kann man auch noch selber Optimierungen bei der TPL vornehmen (Begrenzung der max. Kerne bzw. Threads etc.).

meisse - Sa 11.06.11 17:37

---

Danke für die Antworten.
Ich fasse kurz zusammen: Wenn immer möglich, sollte man die TPL Library verwenden, da diese die optimale Anzahl an Threads aus dem ThreadPool automatisch verwaltet und jeweils die Threads auch optimal auf die Prozessorkerne verteilt (DualCore -> QuadCore -> HexCore).
Mit der "normalen" Thread Programmierung müsste man selber herausfinden, was die optimale Anzahl an Threads wären, um die Kerne der CPU optimal auszulasten.

Mit freundlichen Grüssen
Marius Meier

Kha - Sa 11.06.11 20:34

---

meisse hat folgendes geschrieben :

da diese die optimale Anzahl an Threads aus dem ThreadPool automatisch verwaltet und jeweils die Threads auch optimal auf die Prozessorkerne verteilt

Was erstmal nicht atemberaubend ist ;) . Die optimale Anzahl wird einfach als Environment.ProcessorCount angenommen, das Verteilen auf die Kerne übernimmt das OS. So richtig angenehm macht TPL in dieser Hinsicht das Programmieren erst beispielsweise durch automatisches Partitioning [http://reedcopsey.com/2010/01/26/parallelism-in-net-part-5-partitioning-of-work/].