Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Path to Parallel JavaScript

blog.mozilla.org

Post reply on HN
Print view View original

21–30 of 58 posts

Re: The Path to Parallel JavaScript

#21

Post by amelius »

polskibus wrote: post #11

What's wrong with message passing though - MPI does it, Erlang does it - surely this paradigm can deliver good performance for data and task parallelism. I hope Mozilla will continue experimenting with parallel js. Exciting times!

It starts to become a problem when the messages are very large. Consider the case where you need to send a big set to a thread, so that it can use it as a part of a computation. Conversion to JSON would be too slow, because every element of the set would have to be visited upon invocation.

You often want large computations to be performed in a side-thread (to avoid blocking the UI thread). It would be a pity if such computations couldn't take large data-structures as an argument, because large computations often take large amounts of data as input.

Re: The Path to Parallel JavaScript

#22

Post by azakai »

polskibus wrote: post #11

What's wrong with message passing though - MPI does it, Erlang does it - surely this paradigm can deliver good performance for data and task parallelism. I hope Mozilla will continue experimenting with parallel js. Exciting times!

Message passing can be very efficient for some tasks. But there are cases where it is hard to optimize out copying.

For example, let's say you're running a raytracer, and you have several web workers each render a slice of the frame. Then each worker can transfer back their output to the "main" thread (using existing typed array transfer). But the main thread now has several separate typed arrays, one from each worker. If it wants to combine them all into one contiguous typed array, it needs to do a copy of the data, which is something we'd like to avoid.

In this case, what you really want is to have a single contiguous typed array, and let each worker write to a slice of it. Something similar to that would be possible in what is proposed in the blogpost.

Re: The Path to Parallel JavaScript

#23

Post by justincormack »

azakai wrote: post #22
polskibus wrote: post #11

What's wrong with message passing though - MPI does it, Erlang does it - surely this paradigm can deliver good performance for data and task parallelism. I hope Mozilla will continue experimenting with parallel js. Exciting times!

Message passing can be very efficient for some tasks. But there are cases where it is hard to optimize out copying. For example, let's say you're running a raytracer, and you have several web workers each render a slice of the frame. Then each worker can transfer back their output to the "main" thread (using existing typed array transfer). But the main thread now has several separate typed arrays, one from each worke…

Copying in cache is very fast now. Spending time aboiding copies is no longer always a win like it used to be.

Re: The Path to Parallel JavaScript

#25

Post by amelius »

Joe8Bit wrote: post #18
coderzach wrote: post #12

Earlier quoted context omitted.

Anecdotally, I've found that most performance hick-ups don't come from computation blocking the ui, but from rendering one part of the ui blocking every other part from rendering. The solution to that being parallel or async paint/layout, which is something I never hear mentioned (probably because it's a really hard problem).

Servo is actually in the process of implementing a parallel layout engine[1][2] 1: http://en.wikipedia.org/wiki/Servo_(layout_engine) 2: http://pcwalton.github.io/blog/2014/02/25/revamped-parallel-...

Interesting. I wonder how they handle incremental rendering though. Only the forward-path is described in your reference [2].

Re: The Path to Parallel JavaScript

#26

Post by sunfish »

polskibus wrote: post #11

What's wrong with message passing though - MPI does it, Erlang does it - surely this paradigm can deliver good performance for data and task parallelism. I hope Mozilla will continue experimenting with parallel js. Exciting times!

The shared ArrayBuffer interface being described here is following the philosophy of the Extensible Web Manifesto [0]. The idea is that libraries providing higher-level APIs and programming models, such as message passing, can be built on top of low-level primitives.

[0] https://extensiblewebmanifesto.org/

Re: The Path to Parallel JavaScript

#27

Post by bzbarsky »

justincormack wrote: post #23
azakai wrote: post #22

Earlier quoted context omitted.

Message passing can be very efficient for some tasks. But there are cases where it is hard to optimize out copying. For example, let's say you're running a raytracer, and you have several web workers each render a slice of the frame. Then each worker can transfer back their output to the "main" thread (using existing typed array transfer). But the main thread now has several separate typed arrays, one from each worke…

Copying in cache is very fast now. Spending time aboiding copies is no longer always a win like it used to be.

In cache is key, though.

Decoded image data is 4 bytes per pixel, so a raytraced image of any sort of reasonable size would barely (if at all) fit in L3 cache even on modern processors. And you need to fit both the source and the destination, right?

Re: The Path to Parallel JavaScript

#28

Post by ndesaulniers »

polskibus wrote: post #11

What's wrong with message passing though - MPI does it, Erlang does it - surely this paradigm can deliver good performance for data and task parallelism. I hope Mozilla will continue experimenting with parallel js. Exciting times!

Forgive me if my comment seems ignorant, as I've had experience with MPI and threaded code, but not professionally. I also do not provide any numbers or profiles.

I would think message passing in terms of MPI is acceptable, because "the cost of copying" is insignificant to "the cost of network latency." When you have very little overhead (multiple threads performing atomic operations on shared memory), then "the cost of copying" becomes relatively significant. And if you want to target JS given existing legacy C++ code that probably won't be rewritten, well then the JS execution environment will have to be the one to bend.

Re: The Path to Parallel JavaScript

#29

Post by kibwen »

Joe8Bit wrote: post #18
coderzach wrote: post #12

Earlier quoted context omitted.

Anecdotally, I've found that most performance hick-ups don't come from computation blocking the ui, but from rendering one part of the ui blocking every other part from rendering. The solution to that being parallel or async paint/layout, which is something I never hear mentioned (probably because it's a really hard problem).

Servo is actually in the process of implementing a parallel layout engine[1][2] 1: http://en.wikipedia.org/wiki/Servo_(layout_engine) 2: http://pcwalton.github.io/blog/2014/02/25/revamped-parallel-...

They've recently landed a tool that makes it possible to visualize the parallel rendering: https://github.com/servo/servo/pull/4969

Re: The Path to Parallel JavaScript

#30

Post by lukasm »

coderzach wrote: post #10
lukasm wrote: post #9

Does anyone know what is the origin of async/await? It's very convenient for simple cases, but it makes it very hard to mix synchronous and async code(C#).

How does it make it difficult?

I have encounter this problem https://stackoverflow.com/questions/28708238/catching-except...

Basically, it's hard and prone to bugs.

Post reply on HN