[mistercow]

>Asm.js still has no solution to shared memory threads, which will be an issue for any modern game engine I would imagine.

This feels to me like the elephant in the room, not just for asm.js, but for JS in general. We have Web Workers, and that sounds like a solution, so it dampened the discussion of parallelism on the web. But in a lot of situations, Web Workers just don't cut it. Copying memory back and forth is just too inefficient.

[SigmundA]

I agree, I can appreciate the idea of share nothing threading(web workers) which is more like multi-process rather than multi-threading, it's probably the better model for much of the threading use cases out there. However there are performance critical scenarios where lightweight shared memory threads will always win and will be required if it is to be a valid compile target for c/c++ coded bases.

[nitrogen]

If there's a way to do zero-copy message passing in web workers (or equivalently, overhead-free transfer of object ownership between threads), shared memory may be unnecessary.

[gmac]

This is available in recent versions of Chrome and Firefox, on the form of Transferable objects: https://developer.mozilla.org/en-US/docs/Web/API/Transferabl...

[mistercow]

That helps, but it still means you can only have the data on one thread at a time. What would be a massive help would be if you could split a buffer into non-overlapping views, and transfer each view to a separate worker. Some algorithms would still be challenging or impossible to implement this way, like parallel prefix sum algorithms, but it would still greatly widen the number of things you could do in parallel.

[ris]

Doing such a thing would implicitly require doing shared memory behind the scenes.

[nitrogen]

Yes, at some layer of abstraction there will be the possibility of sharing memory. It's probably better to keep it behind the scenes for all but the most CPU intensive uses.