parallele Programmierung(von 2 auf 8 core = langsamere Software?)
-
Hi,
ich habe ein paar Fragen zur parallelen Programmierung.
Es ist ja wohl so, dass es relativ lange dauert einen thread zu erstellen.
Wenn die Aufgaben zu klein sind, dauert die thread Erstellung länger
als die Bearbeitung und ich mache unter umständen meine Software langsamer als
schneller.Unter .net gibt es ja parallelfor und parallelforeach. Sagen wir man
hatte unter einem Duo-Core Programmiert und man hatte 1Millionen
Rechenschritte und es hatte sich gelohnt das auf mehrere Kerne zu verteilen.Jetzt wird die Software plötzlich auf einen 8 Kern Rechner betrieben.
Das System wird doch jetzt 8 threads erstellen oder? Und dadurch
die Software verlangsamen.Wenn die Anzahl der Rechenschritte vorher unbekannt ist, gibt es vielleicht
so eine art best practice, mit der die Software eine Art aufwandsabschätzung machen kann um dann vielleicht die Anzahl der zu nutzenden Kerne beschränkt?
So dass die Software immer die optimale Anzahl an Kernen nutzt?
-
idR nutzt man deswegen clevere Systeme wie zB parallelfor die das Problem kennen und beachten.
Was genau ist deine Frage?
PS:
idR wird Code nur dann langsamer wenn der Overhead für das Thread Initialisieren einen relevanten Teil der Zeit ausmacht. Sollte das aber der Fall sein, dann ist ja die Ausführungszeit des Programmes minimal und daher eigentlich auch kein Problem.
-
So dass die Software immer die optimale Anzahl an Kernen nutzt?
Die Bibliothek von Microsoft wird das alles schon optimal loesen, zumindestens bei der PPL. Ueber die konkrete Umsetzung in .Net kann ich aber nichts sagen.
so eine art best practice, mit der die Software eine Art aufwandsabschätzung machen kann um dann vielleicht die Anzahl der zu nutzenden Kerne beschränkt?
Das tut sie, es werden 8 Threads bei Programmstart erstellt, dann werden Strategien wie work stealing etc. benutzt.
-
adonis schrieb:
Jetzt wird die Software plötzlich auf einen 8 Kern Rechner betrieben.
Das System wird doch jetzt 8 threads erstellen oder? Und dadurch
die Software verlangsamen.So langsam ist das Erstellen der Threads nun auch wieder nicht. Wenn sich das Erstellen der Threads schon negativ auf die Performance auswirkt, dann ist die Gesamtlaufzeit eh vernachlässigbar und es spielt dann keine Rolle.
Ich hab mich schon länger nicht mehr intensiv mit .NET beschäftigt und weiß nicht, wie das implementiert ist, aber ich schätze, die werden auf einen Thread Pool zurückgreifen und nicht ständig neue Threads erstellen.
-
Hatte ein Video von Bernd Marquardt gesehen, kam glaub raus als Net 4.0 rauskam.
Der meinte ein thread zu erstellen dauert ca genausolange wie 150k additionen.Er hatte es auch auf mehreren Rechnern gezeigt, auf nem Quad und einem 8 Core.
auf einem 8 core war es deutlich langsamer(obwohl 8 hier bestimmt gelogen sind,
4 davon sind ja eher emuliert), es war allerdings nur eine schleife.
mit nem Thread pool wärs beim 2ten mal bestimmt schneller gewesen.Aber warum auch 8Threads erstellen wenn es unnötig ist.
Ob man netzpläne jetzt auch zum Programmieren missbrauchen kann?
Ich werd selbst mal rum experimentieren der duocore steht ja direkt neben mir:)
Aber wie testet man das am besten? Auf dem anderen rechner is vista drauf
und laufen weniger dienste und Programme als auf dem hier.Oder lieber 2 Virtuelle maschinen dafür aufsetzen?
Ne idee wie man annähernd gleiche Bedingungen hinbekommt?
-
adonis schrieb:
Der meinte ein thread zu erstellen dauert ca genausolange wie 150k additionen.
Kann sein. Das sind aber immer noch Nanosekunden.
-
Mechanics schrieb:
Kann sein. Das sind aber immer noch Nanosekunden.
Nicht ganz. Ein paar Mikrosekunden dürften es schon sein.
Edit: Naive Rechnung: 150000 Additionen * 1 Addition/Takt * 3 GHz = 50 µs.
-
Afaik nutzt .NET und andere Sprachen für Schleifenparallelisierung Tasks. Dazu wird zuerst für jeden CPU Kern ein Thread angelegt und die einzelnen Tasks werden dann den Threads zugewiesen. Damit erspart man sich das ständige erstellen von Threads, aber kann gleichzeitig viele kleine Aufgaben parallelisieren.
-
Parallelisierungs-Frameworks verwenden oft spezialisierte Scheduler die darauf ausgelegt sind Work-Items mit geringst möglichem Overhead auf die Worker-Threads zu verteilen.
Eine konkrete Variante sind Work Stealing Scheluder, wie sie z.B. in Cilk verwendet werden.
-
Ich habe eben mal getestet. Auf meinem System (Fedora Linux 17, x86-64, i5, 2.67GHz, 4 core) habe ich 0,189 Sekunden gemessen um 10000 Threads zu erzeugen, also 18,9 Mikrosekunden pro Thread. Wobei ich maximal 800 Threads erzeugen kann. Die Messung war nur möglich, da die Threads sich sofort wieder beendet haben und dadurch das Limit nicht erreicht wurde.
Wobei natürlich ein Threadpool sinnvoller ist, als 800 Threads zu erzeugen. Es sein denn, man hat 800 Cores. Wenn man mehr als 800 Cores hat, sollte man die Systemlimitationen höher setzen. Aber momentan kann ich das nicht testen, da ich keinen Rechner mit mehr als 800 Cores zur Verfügung habe
.
-
adonis schrieb:
ich habe ein paar Fragen zur parallelen Programmierung.
Bei ernsthaften Nutzen der Parallelität kann das Prinzip als solches Dir ausreichend nutzen bringen.
Die Frage nach der Zeit der Threaderstellung ist ggf. dann zweitrangig.
Ciao
MM
-
wie definierst du "ernsthaft"?
