M.: Multithreading in JavaScript

Mahlzeit,

mir ist ein Beitrag untergekommen, der ist evtl. auch für andere interessant :)
Hab mir schon öfter gewünscht, dass JS Multithreading kann.

http://t3n.de/news/web-worker-javascript-556677/

--
42
  1. Hallo M.,

    mir ist ein Beitrag untergekommen, der ist evtl. auch für andere interessant :)
    Hab mir schon öfter gewünscht, dass JS Multithreading kann.

    http://t3n.de/news/web-worker-javascript-556677/

    und hier ist JS Multithreading im Einsatz: http://www.j-berkemeier.de/Mandelbrotmenge.html

    Gruß, Jürgen

  2. Hallo,

    Hab mir schon öfter gewünscht, dass JS Multithreading kann.

    Die meisten Operationen in JavaScript fallen in diese Kategorien:

    1. Interaktion mit dem DOM; Layouting und Painting
    2. Input/Output (hauptsächlich Festplatte und Netzwerk)
    3. Mathematische Berechnungen, Datentransformationen

    1. ist am schlechtesten optimierbar und parallelisierbar. Man kann höchstens in »Transaktionen« arbeiten und das Ende einer Reihe von Änderungen zeichnen
    2. ist immer asynchron und nicht-blockend, also von Natur aus parallel; hier muss oft sogar eine Sequenz hergestellt werden.
    3. ist einfach parallelisierbar, wenn kleine Häppchen rein funktional berechnet werden können.

    Web Worker bieten nur für 3. einen Vorteil, und auch nur bei clientseitigem JavaScript.

    Mathias

    1. Hallo molily,

      Die meisten Operationen in JavaScript fallen in diese Kategorien:

      1. Interaktion mit dem DOM; Layouting und Painting

      2. Input/Output (hauptsächlich Festplatte und Netzwerk)

      3. Mathematische Berechnungen, Datentransformationen

      4. ist am schlechtesten optimierbar und parallelisierbar. Man kann höchstens in »Transaktionen« arbeiten und das Ende einer Reihe von Änderungen zeichnen

      5. ist immer asynchron und nicht-blockend, also von Natur aus parallel; hier muss oft sogar eine Sequenz hergestellt werden.

      6. ist einfach parallelisierbar, wenn kleine Häppchen rein funktional berechnet werden können.

      Web Worker bieten nur für 3. einen Vorteil, und auch nur bei clientseitigem JavaScript.

      1. und 2. laufen möglicherweise non blocking, bleiben aber afaik in einem Thread. Ich habe hier noch nie größere CPU-Auslastungen als 100%/(Anzahl CPU-Kerne) beobachtet.

      Mit Web Worker kann man die CPU-Auslastung auf 100% bringen, weil die Worker-Threads unabhängig voneinander laufen, also "echt parallel".

      Gruß, Jürgen

      1. Meine Herren!

        Die meisten Operationen in JavaScript fallen in diese Kategorien:

        1. Interaktion mit dem DOM; Layouting und Painting
        2. Input/Output (hauptsächlich Festplatte und Netzwerk)
        3. Mathematische Berechnungen, Datentransformationen
        1. und 2. laufen möglicherweise non blocking, bleiben aber afaik in einem Thread.

        Jein, Browser verwalten viele eigene Threads/Prozesse (1,2), die teilweise auch aufeinander warten müssen. Die Zuordnung was asynchron und was synchron abläuft bzw. was sich gegenseitig blockt und was parallel ausgeführt werden kann zu echten Threads/Prozessen kann nicht so trivial vorgenommen werden. Beispielsweise muss der Parser stets darauf warten, bis von der Netzwerk-Schicht neue Daten geliefert werden. Trotzdem werden die beiden Aufgaben von Browser in separaten Threads bearbeitet (3).

        Quellen:

        1. http://www.chromium.org/developers/design-documents/multi-process-architecture

        2. http://www.chromium.org/developers/design-documents/threading

        3. http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/#The_rendering_engines_threads

        --
        “All right, then, I'll go to hell.” – Huck Finn
    2. Meine Herren!

      1. ist einfach parallelisierbar, wenn kleine Häppchen rein funktional berechnet werden können.

      Web Worker bieten nur für 3. einen Vorteil, und auch nur bei clientseitigem JavaScript.

      Und auch nicht in allen Fällen. Wegen der hohen Initialisierungskosten für Worker sind zum Beispiel ungeeignet, um einen MergeSort zu parallelisieren oder Per-Pixel-Kalkulationen vorzunehmen. Und das ist auch nicht die Aufgabe, die sie bewältigen sollen, das bringt die Spezifikation ganz zu Anfang zum Ausdruck:

      This specification defines an API for running scripts in the background independently of any user interface scripts. [...] Workers [...] are relatively heavy-weight, and are not intended to be used in large numbers. For example, it would be inappropriate to launch one worker for each pixel of a four megapixel image.

      --
      “All right, then, I'll go to hell.” – Huck Finn
  3. Mahlzeit,

    mir ist ein Beitrag untergekommen, der ist evtl. auch für andere interessant :)
    Hab mir schon öfter gewünscht, dass JS Multithreading kann.

    http://t3n.de/news/web-worker-javascript-556677/

    Das Verkleinern vieler Bilderchen legt hier den Rechner ziemlich lahm, könnten evntl. Worker die Lösung fürs Problem sein?

    Bin dankbar für Hinweise!

    Horst Dankwart