4 ms·

Is it just me that think "JS" and "parallelism" is a bad idea? I was "stuck" in Java-land for over 10 years, along came NodeJS and saved me. In no small part wa

Is it just me that think "JS" and "parallelism" is a bad idea? I was "stuck" in Java-land for over 10 years, along came NodeJS and saved me. In no small part was the absence of threads part of the success. During my Java days, I saw countless broken attempts at writing parallel code (typically only saved by the Java VM not exploiting all possibilities the spec allows for, such as only updating shared global state at the end of a synchronized block). Along came NodeJS and proved to us lost java souls, that with non-blocking I/O, you don't need hundreds of threads to make performant code. In fact, one thread is enough, also for driving complex UI. Now we're given wonderful new Atomics and SharedBuffer, I bet there will be an underlying expectation that to "keep up" you better start driving complex UI in multiple web workers, because, performance. But the complexity of coding parallel stuff hasn't gone away. Atomics and Run To Completion functions isn't simple. I would not be surprised if I'm two years from now am debugging broken attempts at writing parallel code in something like react-parallel.

Matthias247 10y ago
I think "no parallelism and shared objects" was one of JS best design decisions, as it really fits the event-driven (and thereby callback-driven nature of the target systems and avoids lots of errors. I can't count how often I've seen illegal accesses from callbacks in Java in C#, partly because the people didn't even knew that the callback would not be invoked from the main thread. I don't think that web workers and the shared arraybuffers will make that worse. It's a tiny loophole that let's one exploit parallelism for a number of very specific use cases. For the average UI it's far too complex to use, since it does also not directly allow sharing objects but only byte arrays, which means users would need to care for serialization. So the possibility of misuse is low. For a specific set of applications (audio/video processing stuff, game engines, thinks that are cross compiled from C++) it could be an important building block that allows to exploit parallelism there. And I think in these use-cases the implementors would more likely know what they are doing when the shuffle bytes around.
AgentME 10y ago
What I really like is that SharedArrayBuffer introduces parallelism in a very limited way. We don't have to worry about whether existing javascript and libraries are thread-safe. It's only code that opts into it that's directly affected by parallelism.
Vinnl 10y ago
I think the idea is that this isn't used directly - although of course, we'll have to see that it won't. The mindset is that of the Extensible Web: https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/ Basically, a lot of work is currently being done on WebAssembly and wasm.js. This means that languages will be compiled for browsers, and some of those will need/want parallelism. The question is: what do they need for that? Shared buffers allow for constructs to be built on top to explore what primitives are needed for parallelism for compiler targets.
mistercow 10y ago
Since they're doing shared memory in wasm, the choices are "standardize support for shared memory directly, right off the bat", or "let a dozen wasm libraries implement shared memory for JS in incompatible ways, then reluctantly standardize it after the fact". I think the former option is preferable.
rootlocus 10y ago
I understand that "enterprise java" is something most people loathe, but to be fair it's not the language's fault. Java supports thread pools, callbacks, futures, etc. just like javascript. It's the developers that choose the threading model. > In fact, one thread is enough, also for driving complex UI. Swing and JavaFX are single threaded, and very capable of driving complex UIs. I fail to see how you needed to switch to nodejs (a backend technology) to find this. > better start driving complex UI in multiple web workers, because, performance. UIs have never been parallel. One explanation is the complexity of synchronizing the flow of events coming from the OS (ie input) and to the OS (ie drawing). More on that here [1] [1] https://community.oracle.com/blogs/kgh/2004/10/19/multithreaded-toolkits-failed-dream https://community.oracle.com/blogs/kgh/2004/10/19/multithrea...
- ygra 10y ago
  > UIs have never been parallel. WPF can have multi-threaded UIs, but it's usually not worth the headache. Although I think every control is bound to the Dispatcher of its containing window, so you can only have one thread per window instead of dividing it finer (not that it matters much, the usual rules of doing nothing computation-intensive on the UI thread still apply).
cel1ne 10y ago
Look up communicating sequential processes and never have a problem with multi-threading again.
- camus2 10y ago
  > Look up communicating sequential processes and never have a problem with multi-threading again. Go does that yet still need mutexes, has race conditions and memory corruption.
  - cel1ne 10y ago
    "never have a problem with multi-threading again" was not meant literally. Rather that grasping the concept of "sharing data by communicating" helps you structure your programs.
- throwawayish 10y ago
  Reaaally not that simple.
  - cel1ne 10y ago
    I think it helps a lot. I read about the principle (share data by communicating) 10 years ago and structure most of my multi-threaded apps using BlockingQueues or similar. Didn't have a problem since.
    - throwawayish 10y ago
      It does help a lot in many instances. I've been using 0MQ for this purpose, which facilitates the style nicely. However, things like setup/teardown and configuration are still not at all easy to get right -- and not all problems are apt for this style of concurrency, and it doesn't really change much about optimization; getting the most out of the platform is difficult and takes time, CSP doesn't really make a big difference there.
jasode 10y ago
>Along came NodeJS and proved to us lost java souls, that with non-blocking I/O, you don't need hundreds of threads to make performant code. In fact, one thread is enough, also for driving complex UI. The asynchronous single-thread event loop of Nodejs is helpful for offloading IO-bound tasks but doesn't solve cpu-bound workloads. Therefore, if a programmer wants to develop heavy cpu computations in parallel (rendering, transcoding, image/speech analysis, etc), the "absence of threads" in Nodejs is not relevant to solving those problems. There are many workloads that perform better in a shared-memory multi-thread execution model rather than shared-nothing multi-process (web workers) model. However, that dichotomy doesn't necessarily justify adding shared-memory threads to Javascipt -- it just changes the wording of the question to a higher-level question: Should the Javascript language+runtime evolve to solve heavy cpu-bound workloads? Apparently, enough of the Javscript community said "yes" such that it's been added to ES2017.
the_gipsy 10y ago
> with non-blocking I/O, you don't need hundreds of threads That stands true. No need to use Workers for IO. We won't suddenly have to use it, because it does not solve a problem for most of us (like promises did, for example). > start driving complex UI in multiple web workers I would guess that for 99% of UIs, it would be total overkill to use Workers (you could still offload e.g. AI, in a game). In general, the push comes from WebGL and similar heavy stuff. > something like react-parallel I definitely can see it, especially with redux. Just for the sake of it, someone somewhere will try it.

Matthias247 10y ago

I think "no parallelism and shared objects" was one of JS best design decisions, as it really fits the event-driven (and thereby callback-driven nature of the target systems and avoids lots of errors. I can't count how often I've seen illegal accesses from callbacks in Java in C#, partly because the people didn't even knew that the callback would not be invoked from the main thread. I don't think that web workers and the shared arraybuffers will make that worse. It's a tiny loophole that let's one exploit parallelism for a number of very specific use cases. For the average UI it's far too complex to use, since it does also not directly allow sharing objects but only byte arrays, which means users would need to care for serialization. So the possibility of misuse is low. For a specific set of applications (audio/video processing stuff, game engines, thinks that are cross compiled from C++) it could be an important building block that allows to exploit parallelism there. And I think in these use-cases the implementors would more likely know what they are doing when the shuffle bytes around.

AgentME 10y ago

What I really like is that SharedArrayBuffer introduces parallelism in a very limited way. We don't have to worry about whether existing javascript and libraries are thread-safe. It's only code that opts into it that's directly affected by parallelism.

Vinnl 10y ago

I think the idea is that this isn't used directly - although of course, we'll have to see that it won't. The mindset is that of the Extensible Web: https://extensiblewebmanifesto.org/ https://extensiblewebmanifesto.org/ Basically, a lot of work is currently being done on WebAssembly and wasm.js. This means that languages will be compiled for browsers, and some of those will need/want parallelism. The question is: what do they need for that? Shared buffers allow for constructs to be built on top to explore what primitives are needed for parallelism for compiler targets.

mistercow 10y ago

Since they're doing shared memory in wasm, the choices are "standardize support for shared memory directly, right off the bat", or "let a dozen wasm libraries implement shared memory for JS in incompatible ways, then reluctantly standardize it after the fact". I think the former option is preferable.

rootlocus 10y ago

I understand that "enterprise java" is something most people loathe, but to be fair it's not the language's fault. Java supports thread pools, callbacks, futures, etc. just like javascript. It's the developers that choose the threading model. > In fact, one thread is enough, also for driving complex UI. Swing and JavaFX are single threaded, and very capable of driving complex UIs. I fail to see how you needed to switch to nodejs (a backend technology) to find this. > better start driving complex UI in multiple web workers, because, performance. UIs have never been parallel. One explanation is the complexity of synchronizing the flow of events coming from the OS (ie input) and to the OS (ie drawing). More on that here [1] [1] https://community.oracle.com/blogs/kgh/2004/10/19/multithreaded-toolkits-failed-dream https://community.oracle.com/blogs/kgh/2004/10/19/multithrea...

ygra 10y ago
> UIs have never been parallel. WPF can have multi-threaded UIs, but it's usually not worth the headache. Although I think every control is bound to the Dispatcher of its containing window, so you can only have one thread per window instead of dividing it finer (not that it matters much, the usual rules of doing nothing computation-intensive on the UI thread still apply).

cel1ne 10y ago

Look up communicating sequential processes and never have a problem with multi-threading again.

camus2 10y ago
> Look up communicating sequential processes and never have a problem with multi-threading again. Go does that yet still need mutexes, has race conditions and memory corruption.
- cel1ne 10y ago
  "never have a problem with multi-threading again" was not meant literally. Rather that grasping the concept of "sharing data by communicating" helps you structure your programs.
throwawayish 10y ago
Reaaally not that simple.
- cel1ne 10y ago
  I think it helps a lot. I read about the principle (share data by communicating) 10 years ago and structure most of my multi-threaded apps using BlockingQueues or similar. Didn't have a problem since.
  - throwawayish 10y ago
    It does help a lot in many instances. I've been using 0MQ for this purpose, which facilitates the style nicely. However, things like setup/teardown and configuration are still not at all easy to get right -- and not all problems are apt for this style of concurrency, and it doesn't really change much about optimization; getting the most out of the platform is difficult and takes time, CSP doesn't really make a big difference there.

jasode 10y ago

>Along came NodeJS and proved to us lost java souls, that with non-blocking I/O, you don't need hundreds of threads to make performant code. In fact, one thread is enough, also for driving complex UI. The asynchronous single-thread event loop of Nodejs is helpful for offloading IO-bound tasks but doesn't solve cpu-bound workloads. Therefore, if a programmer wants to develop heavy cpu computations in parallel (rendering, transcoding, image/speech analysis, etc), the "absence of threads" in Nodejs is not relevant to solving those problems. There are many workloads that perform better in a shared-memory multi-thread execution model rather than shared-nothing multi-process (web workers) model. However, that dichotomy doesn't necessarily justify adding shared-memory threads to Javascipt -- it just changes the wording of the question to a higher-level question: Should the Javascript language+runtime evolve to solve heavy cpu-bound workloads? Apparently, enough of the Javscript community said "yes" such that it's been added to ES2017.

the_gipsy 10y ago

> with non-blocking I/O, you don't need hundreds of threads That stands true. No need to use Workers for IO. We won't suddenly have to use it, because it does not solve a problem for most of us (like promises did, for example). > start driving complex UI in multiple web workers I would guess that for 99% of UIs, it would be total overkill to use Workers (you could still offload e.g. AI, in a game). In general, the push comes from WebGL and similar heavy stuff. > something like react-parallel I definitely can see it, especially with redux. Just for the sake of it, someone somewhere will try it.