5 ms·

Oh look another JS vs native benchmark... I still think we're missing the point; we're focusing on the wrong benchmarks. We're putting too much emphasis on JS

Oh look another JS vs native benchmark... I still think we're missing the point; we're focusing on the wrong benchmarks. We're putting too much emphasis on JS speed, when in reality most web apps are behind native because of lack of (perceived) graphics performance. The shortcut out of this requires a greater variety of GPU-accelerated CSS transitions/DOM changes, as well as easier computations and DOM manipulations off the main thread, which cause horribly noticeable UI hiccups. Web Workers are still too primitive (e.g. no DOM access whatsoever) and slow (e.g. no shared memory). Not saying it's unimportant to improve JS's CPU performance; just saying that we're focusing too much on the wrong battle in the war against native.

belluchan 13y ago
Web workers will never have DOM access. They run in a separate process with a separate URL. That's not an issue. You use postMessage to communicate with the workers.
- goldenkey 13y ago
  I'm pretty sure OP knows about postMessage. That wasn't his point. The only way to pass data is through message passing - but the message passing takes only strings. Just object serialization and deserialization in JS is slow enough to make it infeasable to do large-scale transfer between the two without paying for transmuting the data. We need immutable object passing for performance. Or locked mutable object passing (like Rust.) And why not the ability to modify DOM elements with the repaints happening on the main thread?
  - mistercow 13y ago
    >And why not the ability to modify DOM elements with the repaints happening on the main thread? It's not just a matter of repaints. You'd actually have to make the DOM thread safe, which is not trivial.
    - goldenkey 13y ago
      I think locking the DOM might not be too difficult. To have multi-threaded accessors/getters would be insanely tough given the size of the existing code-base. But a single exclusive lock over the DOM could work.
      - mistercow 13y ago
        There are several problem with that. One is that the web worker would block all user input, including scrolling, while you were modifying the DOM. Also, the locking would absolutely have to be manual. Locking before each DOM modification and then unlocking after would be disastrous, since you'd have no guarantees about the DOM's state from one call to the next. And once you introduce manual locking, you're largely defeating all of the safety guaranteed by workers in the first place. Or think of it this way: If you can lock the DOM reliably and efficiently, then you can write code that shares memory by storing data in the DOM, rather than copying it between workers. That would get you most of what you get from ordinary threads, albeit with only one lock available. This would be such a huge convenience and performance win, that if it were possible, they'd have done it to allow memory sharing without going through the DOM at all. That right there should tell you that allowing DOM access from workers by locking is impractical.
  - woogley 13y ago
    You're looking for Transferable Objects: https://developer.mozilla.org/en-US/docs/Web/Guide/Performance/Using_web_workers#Passing_data_by_transferring_ownership_(transferable_objects) https://developer.mozilla.org/en-US/docs/Web/Guide/Performan...
    - deleted 13y ago
      [deleted]
    - goldenkey 13y ago
      Sweet beavus!
    - chongli 13y ago
      Still seems like quite a hack. Why can't we just have immutable objects shared by all webworkers?
  - marcosscriven 13y ago
    I had exactly this issue when trying to make my OpenSCAD port multithreaded in asm.js - the results of each worker took longer to serialise/deserialise than the time saved by doing them in parallel. Unfortunately couldn't even use transferable objects, as the C++ objects in question were CGAL nef polys, and once copied across would be garbage. It would work though if you have objects you can allocate to a specific buffer (I since discovered called a 'bump allocator') https://groups.google.com/forum/m/#!searchin/emscripten-discuss/Marcosscriven/emscripten-discuss/JeLvBMn9X60 https://groups.google.com/forum/m/#!searchin/emscripten-disc...
SigmundA 13y ago
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.
andhow 13y ago
The 'war on native' has multiple fronts and this post is just reporting on one of them. For many apps, I agree that the items you've mentioned are the most significant and progress is also being made on these fronts (e.g., GPU-acceleration of some CSS transitions are already in Firefox; more and more DOM APIs are being exposed to workers). For other apps, though, especially ones using WebGL like games or authoring tools, raw computational throughput is the most significant.
deleted 13y ago
[deleted]

belluchan 13y ago

Web workers will never have DOM access. They run in a separate process with a separate URL. That's not an issue. You use postMessage to communicate with the workers.

goldenkey 13y ago
I'm pretty sure OP knows about postMessage. That wasn't his point. The only way to pass data is through message passing - but the message passing takes only strings. Just object serialization and deserialization in JS is slow enough to make it infeasable to do large-scale transfer between the two without paying for transmuting the data. We need immutable object passing for performance. Or locked mutable object passing (like Rust.) And why not the ability to modify DOM elements with the repaints happening on the main thread?
- mistercow 13y ago
  >And why not the ability to modify DOM elements with the repaints happening on the main thread? It's not just a matter of repaints. You'd actually have to make the DOM thread safe, which is not trivial.
  - goldenkey 13y ago
    I think locking the DOM might not be too difficult. To have multi-threaded accessors/getters would be insanely tough given the size of the existing code-base. But a single exclusive lock over the DOM could work.
    - mistercow 13y ago
      There are several problem with that. One is that the web worker would block all user input, including scrolling, while you were modifying the DOM. Also, the locking would absolutely have to be manual. Locking before each DOM modification and then unlocking after would be disastrous, since you'd have no guarantees about the DOM's state from one call to the next. And once you introduce manual locking, you're largely defeating all of the safety guaranteed by workers in the first place. Or think of it this way: If you can lock the DOM reliably and efficiently, then you can write code that shares memory by storing data in the DOM, rather than copying it between workers. That would get you most of what you get from ordinary threads, albeit with only one lock available. This would be such a huge convenience and performance win, that if it were possible, they'd have done it to allow memory sharing without going through the DOM at all. That right there should tell you that allowing DOM access from workers by locking is impractical.
- woogley 13y ago
  You're looking for Transferable Objects: https://developer.mozilla.org/en-US/docs/Web/Guide/Performance/Using_web_workers#Passing_data_by_transferring_ownership_(transferable_objects) https://developer.mozilla.org/en-US/docs/Web/Guide/Performan...
  - deleted 13y ago
    [deleted]
  - goldenkey 13y ago
    Sweet beavus!
  - chongli 13y ago
    Still seems like quite a hack. Why can't we just have immutable objects shared by all webworkers?
- marcosscriven 13y ago
  I had exactly this issue when trying to make my OpenSCAD port multithreaded in asm.js - the results of each worker took longer to serialise/deserialise than the time saved by doing them in parallel. Unfortunately couldn't even use transferable objects, as the C++ objects in question were CGAL nef polys, and once copied across would be garbage. It would work though if you have objects you can allocate to a specific buffer (I since discovered called a 'bump allocator') https://groups.google.com/forum/m/#!searchin/emscripten-discuss/Marcosscriven/emscripten-discuss/JeLvBMn9X60 https://groups.google.com/forum/m/#!searchin/emscripten-disc...

SigmundA 13y ago

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.

andhow 13y ago

The 'war on native' has multiple fronts and this post is just reporting on one of them. For many apps, I agree that the items you've mentioned are the most significant and progress is also being made on these fronts (e.g., GPU-acceleration of some CSS transitions are already in Firefox; more and more DOM APIs are being exposed to workers). For other apps, though, especially ones using WebGL like games or authoring tools, raw computational throughput is the most significant.

deleted 13y ago

[deleted]