5 ms·

I don't know much about web workers. According to my understanding, they can only communicate by message passing. This means that, if I have a 50K array and wis

I don't know much about web workers. According to my understanding, they can only communicate by message passing. This means that, if I have a 50K array and wish to sort it via a web worker, I must copy it twice: once incoming and again outgoing. This copying is likely to be as expensive as sorting it (well, maybe not if you use bubble sort). How do you mitigate this?

afshinmeh 11y ago
Well, its just a demonstration to show that a huge cpu-bound task can be done inside the web browser. To be honest, I'm not sure if it worth to use it in production.
- rrss1122 11y ago
  I would say not having that UI lag while doing a huge cpu-bound task would be worth it in production.
Drakim 11y ago
Fortunately, Transferable Objects (which didn't arrive until a bit after Web Workers) solves this :) http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fast http://updates.html5rocks.com/2011/12/Transferable-Objects-L...
- afshinmeh 11y ago
  I didn't know this, awesome.
- amelius 11y ago
  If one wants to share data with two different web-workers (doing different computations on the same immutable data), there is still a problem. Or so I suppose (?)
  - Drakim 11y ago
    Yeah, you'd have to clone the data.
- angersock 11y ago
  Note that IE can have some issues with transferable objects. Also note that the messages cannot encapsulate, say, closures or anything else that you can't JSON.stringify()/JSON.parse().
- rrss1122 11y ago
  Looks like the OP's linked example does not use this, since the sort reported that it took longer when using web workers than when it didn't use web workers, at least a full second longer. I wonder how much performance would improve if the example did use Transferable Objects.
CyberDildonics 11y ago
It is still a huge win since copying is both O(N) and cache coherent, while sorting is of course O(N log(N))
bgirard 11y ago
You vastly overestimate the cost of copying 50k elements. On low end mobile you'll get at least 1GB/sec and on desktop you can get easily 10GB/sec. Now sorting at these speeds is a whole other story. The real thing to consider is if the latency of the round trip messaging is less than just doing the work in place. With something like web workers you're going to have to hit the event loops when messaging back and forth which aren't always empty.

afshinmeh 11y ago

Well, its just a demonstration to show that a huge cpu-bound task can be done inside the web browser. To be honest, I'm not sure if it worth to use it in production.

rrss1122 11y ago
I would say not having that UI lag while doing a huge cpu-bound task would be worth it in production.

Drakim 11y ago

Fortunately, Transferable Objects (which didn't arrive until a bit after Web Workers) solves this :) http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fast http://updates.html5rocks.com/2011/12/Transferable-Objects-L...

afshinmeh 11y ago
I didn't know this, awesome.
amelius 11y ago
If one wants to share data with two different web-workers (doing different computations on the same immutable data), there is still a problem. Or so I suppose (?)
- Drakim 11y ago
  Yeah, you'd have to clone the data.
angersock 11y ago
Note that IE can have some issues with transferable objects. Also note that the messages cannot encapsulate, say, closures or anything else that you can't JSON.stringify()/JSON.parse().
rrss1122 11y ago
Looks like the OP's linked example does not use this, since the sort reported that it took longer when using web workers than when it didn't use web workers, at least a full second longer. I wonder how much performance would improve if the example did use Transferable Objects.

CyberDildonics 11y ago

It is still a huge win since copying is both O(N) and cache coherent, while sorting is of course O(N log(N))

bgirard 11y ago

You vastly overestimate the cost of copying 50k elements. On low end mobile you'll get at least 1GB/sec and on desktop you can get easily 10GB/sec. Now sorting at these speeds is a whole other story. The real thing to consider is if the latency of the round trip messaging is less than just doing the work in place. With something like web workers you're going to have to hit the event loops when messaging back and forth which aren't always empty.