4 ms·

WebGL anyone? This is what does most of the heavy lifting in the main asm.js use case: games. I am still waiting to see a UI framework built using asm.js and W

WebGL anyone? This is what does most of the heavy lifting in the main asm.js use case: games. I am still waiting to see a UI framework built using asm.js and WebGL. Maybe even a existing native framework ported over, something like WPFe(Silverlight) might be about as difficult as a game engine to port. Asm.js still has no solution to shared memory threads, which will be an issue for any modern game engine I would imagine.

mistercow 13y ago
>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 13y ago
  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 13y ago
    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.
    - ris 13y ago
      Doing such a thing would implicitly require doing shared memory behind the scenes.
      - nitrogen 13y ago
        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.
    - gmac 13y ago
      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/Transferable https://developer.mozilla.org/en-US/docs/Web/API/Transferabl...
      - mistercow 13y ago
        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.
sitkack 13y ago
The js app performance will be a "solved" problem in 4 years. * WebCL will be widely deployed, better penetration than current WebGL * Web workers will be able to share typed arrays by reference (see Mozilla's Transferable Objects) * Other vectorization libraries will be available (Rivertrail) http://blog.aventine.se/post/16318162396/simd http://www.khronos.org/webcl/ https://github.com/RiverTrail/RiverTrail
- jnbiche 13y ago
  Why do you think WebCL will be widely-deployed in 4 years? I used to think that, not I'm not so sure. It's sure not been given a warm welcome by any of the major browsers. I'm not sure I share your optimism. I do agree that Transferable Objects will be a tremendous boon, and should address all the shared memory thread complaints elsewhere in these comments. I had forgotten about RiverTrail. Very cool project, but is it even still in active development? Commits seemed to have trailed off.
  - sitkack 13y ago
    heh, trailed off. ---- Because WebGL will be based off of WebCL, WebGL is a subset targeted at graphics. And change is accelerating, everything in the future happens faster. So there will be more people to implement WebCL than there was to implement WebGL. More and more people are using advanced web apps so the pressure is higher to make things faster.

mistercow 13y ago

>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 13y ago
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 13y ago
  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.
  - ris 13y ago
    Doing such a thing would implicitly require doing shared memory behind the scenes.
    - nitrogen 13y ago
      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.
  - gmac 13y ago
    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/Transferable https://developer.mozilla.org/en-US/docs/Web/API/Transferabl...
    - mistercow 13y ago
      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.

sitkack 13y ago

The js app performance will be a "solved" problem in 4 years. * WebCL will be widely deployed, better penetration than current WebGL * Web workers will be able to share typed arrays by reference (see Mozilla's Transferable Objects) * Other vectorization libraries will be available (Rivertrail) http://blog.aventine.se/post/16318162396/simd http://www.khronos.org/webcl/ https://github.com/RiverTrail/RiverTrail

jnbiche 13y ago
Why do you think WebCL will be widely-deployed in 4 years? I used to think that, not I'm not so sure. It's sure not been given a warm welcome by any of the major browsers. I'm not sure I share your optimism. I do agree that Transferable Objects will be a tremendous boon, and should address all the shared memory thread complaints elsewhere in these comments. I had forgotten about RiverTrail. Very cool project, but is it even still in active development? Commits seemed to have trailed off.
- sitkack 13y ago
  heh, trailed off. ---- Because WebGL will be based off of WebCL, WebGL is a subset targeted at graphics. And change is accelerating, everything in the future happens faster. So there will be more people to implement WebCL than there was to implement WebGL. More and more people are using advanced web apps so the pressure is higher to make things faster.