4 ms·

I'm not sure how this addresses the resource load of Web Workers. What about their alternative makes it inherently lighter? I agree that there is an issue her

by Lerc 9y ago

I'm not sure how this addresses the resource load of Web Workers. What about their alternative makes it inherently lighter? I agree that there is an issue here, but this feels like making another thing with bits added. To genuinely make it lighter weight, would it not need to be a subset of capability. Otherwise why couldn't the efficiency just be added to Workers? The problem seems to be that Workers can only really applied to fairly substantial workloads. Trivial tasks (x=y+1) can be done on the main JavaScript Thread. There needs to be something for the middle ground. At a minimum I would have thought that such a solution should enable a parallel form of map, filter, and reduce style operations. These are operations that are intrinsically designed for non-trivial tasks. I feel that there might need to be a way to distinguish some sort of function purity before such parallelism is allowed, lest JavaScript turn into a soup of races and conflicts. A way to declare (or ideally automatically identify) functions that do not mutate global state and return a value created from inside the function. Workers handle persistent parallel processing with async communication. I suspect maintaining that complete persistent state is why the resource load is so high. The lightweight middle-ground should offer non-persistent parallelism.

jerf 9y ago
"I'm not sure how this addresses the resource load of Web Workers. What about their alternative makes it inherently lighter?" The running of multiple tasklets within one WebWorker, from the sounds of it. Given that there is a polyfill directory in the repo, and that nothing in what they've described immediately strikes me as needing any more browser support (give or take perhaps some quirky corner) for an initial implementation, it sounds like it's mostly stuff you could in theory write yourself. There's probably hundreds of similar things out there in the world already. But standardizing is often helpful, and there are ways the browser engine could theoretically accelerate these methods if they are explicitly supported with defined semantics the browser can understand. In particular, if the JIT can prove you are sending a "message" using this API that is a pure data object, it doesn't have to serialize that to a bytestream on one side and deserialize it on the other; it can just transfer the object via pointer passing. Or if it must still serialize/deserialize across a boundary, at least use a mechanism written in C++ that can be more efficient and easier than anything you can write in native JS. (I say 'browser' above to leave open the possibility of DOM node proxying or whathaveyou; of course it would work in Node too.) "At a minimum I would have thought that such a solution should enable a parallel form of map, filter, and reduce style operations. These are operations that are intrinsically designed for non-trivial tasks." Surely these already exist somewhere? (If I know my JS library world, several dozen times over.) They should transfer over into the tasklet just fine. Not sure this is worth it's own comment, so I'll just add that this strikes me as putting apartment-style threading into the browser: https://msdn.microsoft.com/en-us/library/ms809971.aspx https://msdn.microsoft.com/en-us/library/ms809971.aspx based on a cooperative scheduling process, built on top of a dynamic scripting language. This would put the browser tech stack now somewhere in 2000-2001, I think. (This style of threading leans 1990s, but JS is better than any dynamic scripting language was in that timeframe, so I'll bump it forward a bit. But then back again for being cooperatively threaded.) It's getting there... But in all seriousness, to the team looking at this, I would strongly suggest considering what this means in a world of WebAssembly, not just pure JS. Perhaps it all just works as-is, but it would still be nice to see some text about it.
- Lerc 9y ago
  >Surely these already exist somewhere? (If I know my JS library world, several dozen times over.) The problem is the access to data. You have to pass data to a Worker. To take the canonical embarrassingly parallel task, ray-tracing, each ray can be executed in parallel but they all refer to a common scene. Passing the scene on a per-ray basis would lose any gains. Passing a scene then doing a batch of rays is only 'slightly parallel' consider a list of points and you want to make a table showing their relative distances var distances = list.map(a=>list.map(b=>distance(a,b))); That's something that has plenty of potential for parallelism, but to do so the function inside the first map also needs be able to see the list. What I really want is something where I can write a piece of code as simple as that where it will run on as many cores as the host device has available.
  - CuriousSkeptic 9y ago
    You would need immutability (or a static type system) to do that safely though. And I don’t think you can check the closed over objects before the closure is actually scheduled to execute (perhaps if you limit the closure to const references) But, since you can pass a context explicitly to map and friends you might get away with checking that for immutability.
iainmerrick 9y ago
A way to declare (or ideally automatically identify) functions that do not mutate global state and return a value created from inside the function. Yes, I think that’s exactly the right idea.

by Lerc 9y ago

jerf 9y ago

"I'm not sure how this addresses the resource load of Web Workers. What about their alternative makes it inherently lighter?" The running of multiple tasklets within one WebWorker, from the sounds of it. Given that there is a polyfill directory in the repo, and that nothing in what they've described immediately strikes me as needing any more browser support (give or take perhaps some quirky corner) for an initial implementation, it sounds like it's mostly stuff you could in theory write yourself. There's probably hundreds of similar things out there in the world already. But standardizing is often helpful, and there are ways the browser engine could theoretically accelerate these methods if they are explicitly supported with defined semantics the browser can understand. In particular, if the JIT can prove you are sending a "message" using this API that is a pure data object, it doesn't have to serialize that to a bytestream on one side and deserialize it on the other; it can just transfer the object via pointer passing. Or if it must still serialize/deserialize across a boundary, at least use a mechanism written in C++ that can be more efficient and easier than anything you can write in native JS. (I say 'browser' above to leave open the possibility of DOM node proxying or whathaveyou; of course it would work in Node too.) "At a minimum I would have thought that such a solution should enable a parallel form of map, filter, and reduce style operations. These are operations that are intrinsically designed for non-trivial tasks." Surely these already exist somewhere? (If I know my JS library world, several dozen times over.) They should transfer over into the tasklet just fine. Not sure this is worth it's own comment, so I'll just add that this strikes me as putting apartment-style threading into the browser: https://msdn.microsoft.com/en-us/library/ms809971.aspx https://msdn.microsoft.com/en-us/library/ms809971.aspx based on a cooperative scheduling process, built on top of a dynamic scripting language. This would put the browser tech stack now somewhere in 2000-2001, I think. (This style of threading leans 1990s, but JS is better than any dynamic scripting language was in that timeframe, so I'll bump it forward a bit. But then back again for being cooperatively threaded.) It's getting there... But in all seriousness, to the team looking at this, I would strongly suggest considering what this means in a world of WebAssembly, not just pure JS. Perhaps it all just works as-is, but it would still be nice to see some text about it.

Lerc 9y ago
>Surely these already exist somewhere? (If I know my JS library world, several dozen times over.) The problem is the access to data. You have to pass data to a Worker. To take the canonical embarrassingly parallel task, ray-tracing, each ray can be executed in parallel but they all refer to a common scene. Passing the scene on a per-ray basis would lose any gains. Passing a scene then doing a batch of rays is only 'slightly parallel' consider a list of points and you want to make a table showing their relative distances var distances = list.map(a=>list.map(b=>distance(a,b))); That's something that has plenty of potential for parallelism, but to do so the function inside the first map also needs be able to see the list. What I really want is something where I can write a piece of code as simple as that where it will run on as many cores as the host device has available.
- CuriousSkeptic 9y ago
  You would need immutability (or a static type system) to do that safely though. And I don’t think you can check the closed over objects before the closure is actually scheduled to execute (perhaps if you limit the closure to const references) But, since you can pass a context explicitly to map and friends you might get away with checking that for immutability.

iainmerrick 9y ago

A way to declare (or ideally automatically identify) functions that do not mutate global state and return a value created from inside the function. Yes, I think that’s exactly the right idea.