Multi-threading with web worker
1 1 2 
molily
Multi-threading with web worker
Hallo,
Mit HTML5 und web workers ist ja nun de-facto multi-threading auch mit Javascript möglich. Ich will einige intensive Berechnungen in web worker auslagern. Nun meine Frage, die ich mit Google so einfach nicht beantworten konnte. Ist es sinnvoll, mehrer web worker gleichzeitig zu erstellen und die Arbeit zur Berechnung darauf zu verteilen, oder sollte ich nur einen web worker mit der Berechnung laufen lassen? Werden mit jedem web worker auch jeweils eigene threads gestartet oder ist das auch abhängig von der jeweiligen Hardware (Multicore CPU etc.) bzw. Browser-Implementierung? Ich würde gerne mehr darüber erfahren, bevor ich etwas implementiere, was nur auf der Hälfte der Hardware, oder der Browser mit web worker Unterstützung funktioniert.
Vielen Dank für mögliche Erleuchtung meinerseits
Gruss, Steffen
-
Moin Steffem,
Nun meine Frage, die ich mit Google so einfach nicht beantworten konnte. Ist es sinnvoll, mehrer web worker gleichzeitig zu erstellen und die Arbeit zur Berechnung darauf zu verteilen, oder sollte ich nur einen web worker mit der Berechnung laufen lassen?
Das ist so nicht zu beantworten, da wichtige Informationen fehlen:
- Ist die Berechnung I/O-intensiv, macht sie also z. B. viele HTTP-Requests?
- Ist die Berechnung einfach verteilbar auf mehrere Threads? Oder ist dafür viel Verwaltungs-Overhead nötig?
Ist eine Berechnung sehr I/O-intensiv oder einfach verteilbar, lohnt es sich auf jeden Fall Cores + 1 Thread zu erstellen. Benötigst du viel Verwaltungsaufwand zur Koordination der Threads, lohnt es sich eher nicht.
Bedenke aber: „Workers (as these background scripts are called herein) are relatively heavy-weight, and are not intended to be used in large numbers.“ (aus der Spec).
Werden mit jedem web worker auch jeweils eigene threads gestartet oder ist das auch abhängig von der jeweiligen Hardware (Multicore CPU etc.) bzw. Browser-Implementierung?
Die Spec schreibt vor, dass ein „separate parallel execution environment“ erstellt wird, was das bedeutet überlässt sie aber dem Browser-Hersteller. Es könnte ein Thread sein oder aber auch ein neuer Prozess.
Ich würde gerne mehr darüber erfahren, bevor ich etwas implementiere, was nur auf der Hälfte der Hardware, oder der Browser mit web worker Unterstützung funktioniert.
LG,
CK-
Vielen Dank fuer die Antwort,
hat mir schon etwas weiter geholfen. Ich werde es erst einmal mit einem worker versuchen und schauen, ob es sich dann lohnt, noch etwas mehr Performance herauszuholen.
Moin Steffem,
Nun meine Frage, die ich mit Google so einfach nicht beantworten konnte. Ist es sinnvoll, mehrer web worker gleichzeitig zu erstellen und die Arbeit zur Berechnung darauf zu verteilen, oder sollte ich nur einen web worker mit der Berechnung laufen lassen?
Bedenke aber: „Workers (as these background scripts are called herein) are relatively heavy-weight, and are not intended to be used in large numbers.“ (aus der Spec).
Ja, stimmt. Ich habe jetzt auch gelesen, dass zum Beispiel Chrome bei workers >50 schon Probleme bekommt und instabil wird.
Die Spec schreibt vor, dass ein „separate parallel execution environment“ erstellt wird, was das bedeutet überlässt sie aber dem Browser-Hersteller. Es könnte ein Thread sein oder aber auch ein neuer Prozess.
Es scheint also ganz so, als ob es hier darauf ankommt, wie gut oder schlecht der entsprechende Browser die Hardware nutzen kann. Gut zu wissen, dass es aber grundsaetzlich keine konkreteren Vorgaben gibt.
Allgemein bin ich aber schon sehr beeindruckt, was einem nun mit workern zur Verfuegung steht, dass vorher einfach nicht sinnvoll umzusetzen war. Ich muss jetzt nur noch herausfinden, ob es beim Worker auch zum "verschlucken" von messages kommen kann, wenn zum Beispiel der worker antwortet, aber die eigentlich Seite gerade viel Veraenderungen im Dom vornimmt. Aber dass geht wohl nur ueber testen ;-)
Vielen Dank noch einmal!
-
Ist es sinnvoll, mehrer web worker gleichzeitig zu erstellen und die Arbeit zur Berechnung darauf zu verteilen, oder sollte ich nur einen web worker mit der Berechnung laufen lassen?
Ob und wann es sinnvoll ist hat Christan ja schon beantwortet. Der schlimmste Seiteneffekt von rechenentensiven Aufgaben, nämlich das Gefrieren der Benutzeroberfläche, wird auch schon durch einen Worker vermieden.
-
Ist es sinnvoll, mehrer web worker gleichzeitig zu erstellen und die Arbeit zur Berechnung darauf zu verteilen
In der Regel ja. Natürlich unter der Voraussetzung, dass sich die Aufgabe sinnvoll zerteilen und parallelisieren lässt. Davon abgesehen, dass nicht alle Browser Web Workers unterstützen, unterstützen auch nicht alle das Senden von komplexen Daten. Und wenn, dann werden sie serialisiert und deserialisiert, damit geklont. Das ist der angesprochene Overhead. Erst Transferable Objects werden das Problem lösen. In älteren Browsern müssen ggf. manuell JSON-Strings verschickt werden. Hier ist eine Feature-Abfrage nötig, um diese Browser ggf. auszuschließen.
oder sollte ich nur einen web worker mit der Berechnung laufen lassen?
Das kann man so pauschal nicht beantworten, das solltest du einfach ausprobieren. Probiere mit einem Pool von 5-10 Workern und finde den Punkt, wo keine Verbesserungen mehr erzielt werden können.
Werden mit jedem web worker auch jeweils eigene threads gestartet oder ist das auch abhängig von der jeweiligen Hardware (Multicore CPU etc.) bzw. Browser-Implementierung?
Web Workers können mehrere Prozessorkerne nutzen, ja. Die tatsächliche Umsetzung hängt vom Browser, Prozessor und vom Betriebssystem ab. Wenn in einem Browser 10 Worker eine optimale Performance bringen, kann es sein, dass ein anderer mit 5 ausgelastet ist (bei gleicher Hardware).
Ich würde gerne mehr darüber erfahren, bevor ich etwas implementiere, was nur auf der Hälfte der Hardware, oder der Browser mit web worker Unterstützung funktioniert.
Da kannst du eigentlich nichts falsch machen, funktionieren wird es immer – außer du schießt den Browser ab oder die Performance geht in den Keller. Da musst du durch Ausprobieren mit deinem konkreten Algorithmus Erfahrungen sammeln. Wie immer in der Webentwicklung musst du ohnehin in verschiedenen Browsern und auf verschiedenen Systemen testen, um einen sinnvollen Weg zu finden.
Mathias
-
Vielen Dank fuer die Antwort,
ich denke ich habe jetzt einen ganz guten Überblick, wo die tückischen Stellen bei workern liegen. Allgemein aber schon eine wesentliche Bereicherung für echte Web-Applikationen. Warum allerdings ein DOM Parser und xmlhttprequest mit responseXML nicht im Worker intergriert sind, erschliesst sich mir nicht. Es wird zwar auf Stabilitaetsüberlegungen verwiesen, aber ich will ja nicht auf den DOM Kontext zugreifen, aus dem der worker gestartet wurde. Mal eben 50+ xml Dokumente mit einem worker einlesen und parsen ist weiterhin problematisch und nicht allein im worker zu lösen. Aber das war nicht der Hauptgrund, warum ich den worker brauche.
Jetzt geht es ans optimieren und schauen, wo noch die ein oder andere Millisekunde Wartezeit entfernt werden kann.
Gruss,
Steffen
-