nicht angemeldet Michael_K
TS
klawischnigg
Michael_K
Felix Riesterer
TS
JürgenB
Hallo,
ich bin auf der Suche nach Informationen, wie man WebWorker sinnvoll für MultiCore CPUs anwendet. Ich habe nun schon etwas gegoogelt, aber mal als die Info, dass WebWorker MultiCode CPUs sinnvoll nutzen können, habe ich noch nicht gefunden. Mir geht es insbesondere um die Frage, wie man die Arbeitslast auf mehrere Worker sinnvoll verteilt.
Wenn dazu Infoseite zum nachlesen kennt, ich würde mich freuen.
Gruss
Hello,
soll es etwas in dieser Richtung sein?
Glück Auf
Tom vom Berg
Moin,
danke für den Link. Wie WebWorker funktionieren weiss ich und sind auch schon im Einsatz. Mir geht es aber darum, wie man WebWorker sinnvoll programmiert, damit man optimal die Leistung einer MultiCore-CPU anspricht. Dank AMD sind ja nun CPUs mit >10 Threads keine Seltenheit mehr.
Es gibt ja Analysen, welche Form der Iteration bei JavaScript am schnellsten sind. Und so etwas suche ich nun auch für den Einsatz von WebWorker. Zum Beispiel: Ist es eher besser, die Arbeit auf >1000 Worker zu verteilen? Oder hat die JS-Engine damit eher Probleme und man sollte die Anzahl der Worker nicht zu groß werden lassen. Also ich bin auf der Suche nach Literatur, die sich der Frage annimmt, wie man rechenintensive Aufgaben sinnvoll verteilt, damit die Leistung der CPU voll ausgenutzt = schneller fertig ist mit der Berechnung/Analyse.
Hallo,
mir ist das Webworker-Konzept nur oberflächlich vertraut, darum nur ein paar allgemeine Denkanstöße.
Mir geht es aber darum, wie man WebWorker sinnvoll programmiert, damit man optimal die Leistung einer MultiCore-CPU anspricht.
Das hängt sehr stark von der Aufgabe ab.
Kann man die Aufgabe in Teilaspekte zerlegen, die voneinander unabhängig sind? - Dann ist eine Aufteilung auf mehrere Threads möglicherweise sinnvoll.
Ist die Aufgabe aber eher auf eine sequentielle Bearbeitung angewiesen, ist also der nächste Schritt vom vorherigen abhängig? - Dann bringt die Aufteilung relativ wenig.
Zum Beispiel: Ist es eher besser, die Arbeit auf >1000 Worker zu verteilen?
IMO eher nicht. Dann ist der Verwaltungs-Overhead so groß, dass er den möglichen Vorteil der Parallelisierung aufzehrt.
Ich empfehle daher, nicht mehr Threads (Workers) zu generieren, als eine typische, durchschnittliche CPU Cores hat, zum Beispiel vier. Bei einer echten High-End-CPU mit 12 Cores verschenkst du damit wohl ein bisschen, aber die Mehrheit der CPUs kann das dann ganz gut umsetzen und optimieren.
Just my 2 cents,
Martin
Hi there,
ich bin auf der Suche nach Informationen, wie man WebWorker sinnvoll für MultiCore CPUs anwendet. Ich habe nun schon etwas gegoogelt, aber mal als die Info, dass WebWorker MultiCode CPUs sinnvoll nutzen können, habe ich noch nicht gefunden. Mir geht es insbesondere um die Frage, wie man die Arbeitslast auf mehrere Worker sinnvoll verteilt.
Ohne es jetzt zu wissen, aber wieso glaubst Du, daß Du das beeinflußen kannst? Javascript läuft im Browser und damit entscheidet die Browser-Engine, wieviel Kerne und Ressourcen genutzt werden. Wie gesagt, ohne mich da im Detail eingelesen zu haben, aber ich denke, daß Du mit Javascript generell nicht auf diese maschinennahe Ebene kommst, wo Du, sei es mit WebWorkern oder nicht, eine Aufgabenverteilung an einzelne CPU-Kerne bestimmen kannst...
Das ist ja genau das, was mich interessiert. Wenn ich normale "Schleifen" durchlaufen, dann hängt das ja auch von der JS-Engine ab. Und trotzdem gibt es gute Literatur, wie man dies auf Basis der vorhandenen JS-Engines am besten gestalten sollte.
Mich würde eben genau interessieren, wie die JS-Engines mit Worker optimal umgehen und wie man mit dem Wissen dann die Worker ausgestaltet:
Wann sind WebWorker schneller? Wo liegen die Performanceunterschiede bei vielen einzelnen Workern im Vergleich zu einem SharedWorker? usw. usw.
Lieber Michael_K,
ich habe unlängst etwas davon gelesen, dass sich Funktionsaufrufe sehr gut parallelisieren ließen. Eine echte for-Schleife muss auf einem Thread laufen, was nicht weiter verwunderlich ist. Aber wenn das über Funktionsaufrufe wie Array.forEach geschieht, würde jede Iteration einen Funktionsaufruf bedeuten, welche von verschiedenen Threads abgearbeitet werden könnte - so die JS-Engine das unterstützt.
Liebe Grüße
Felix Riesterer
Hello Felix,
ich habe unlängst etwas davon gelesen, dass sich Funktionsaufrufe sehr gut parallelisieren ließen. Eine echte
for-Schleife muss auf einem Thread laufen, was nicht weiter verwunderlich ist. Aber wenn das über Funktionsaufrufe wieArray.forEachgeschieht, würde jede Iteration einen Funktionsaufruf bedeuten, welche von verschiedenen Threads abgearbeitet werden könnte - so die JS-Engine das unterstützt.
Wo gibt es denn noch Programmiersprachen, die ein for noch bis auf ein repnz o. ä. (je nach Prozessor) herunterbrechen?
Ich habe früher viel Grafikroutinen geschrieben. Und man will gar nicht glauben, was man da an Zeit beim Bildaufbau sparen konnte, wenn man "echte Forschleifen" benutzt hat.
Glück Auf
Tom vom Berg
Hallo Michael,
die Frage, auf wieviele Threads die Aufgabe verteilt werden soll, ist so allgemein nicht zu beantworten, und die optimale Anzahl lässt sich wahrscheinlich auch nur durch Tests ermitteln. Denn auf der einen Seite kannst du mit mehr Threads die Arbeit besser auf die vorhandenen CPUs bzw. Kerne verteilen, andererseits müssen die Threads auch verwaltet werden. U.A. müssen die Ergebnisse ja auch wieder eingesammelt werden. Gefühlsmäßig würde ich nicht mehr Threads nehmen, als CPU-Kerne vorliegen.
Auf dieser Seite kannst du die Threadzahl einstellen und in der Browserkonsole die CPU-Zeiten sehen.
In einer anderen Antwort hast du von >1000 Workern geschrieben. Wenn sich dein Problem auf so viele Threads verteilen lässt, und wenn du keine Double Precision Numerik brauchst, wäre evtl. das Rechnen auf der Grafikkarte etwas für dich. Ich habe von der oben verlinkten Seite auch eine GPU-Version erstellt.
Gruß
Jürgen
Der Martin