4 ms·

Performs better than most websites which intentionally target JS

by sparsely 8y ago

chrisco255 8y ago
You mean the DOM. The web isn't slow because of JS.
- blotter_paper 8y ago
  Slow is relative, and JS is slow relative to WASM.
  - rat9988 8y ago
    I can't tell what you are trying to refute in your parent comment.
    - blotter_paper 8y ago
      I'm saying that the web is slow because of JS, not just the DOM (though I'm not contending that the DOM isn't the bigger issue).
      - chrisco255 8y ago
        No its not. JS is extremely fast. The demo above is Java compiled to JS, NOT webassembly.
        blotter_paper 8y ago
        Again, slow is relative, and JS is slow relative to WASM. That should be obvious, but here's a source.[0] A demo working smoothly does not mean that a language is not slow compared to another. Besides this point, there are some very processing heavy tasks that we're throwing in browsers these days; this demo is not representative of everything we expect browsers to run. And if you read the other comments here, some people were having lag issues with the demo anyway. [0]: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-...
        konsoletyper 8y ago
        No, WASM is slow. As a developer of TeaVM I can claim this. First of all, JS engines been developed for many years, while WASM is a new technology and browser engines don't optimize it well. Another reason is WASM was not designed to run languages like Java, at least in version 1.0. Here are the reasons: * To make GC work properly you have to maintain GC roots. GC roots are static fields + variables in stack. There's no way in WASM to walk the stack! You have to maintain your own shadow stack, losing performance. In case of generating native code (e.g. x86/64) you can access native stack freely and finding GC roots produces no overhead (which is already done by JS engines). * To make exceptions work properly, you need to walk the stack, and not only read it, but also write to it (in case of x86, update RSP direcly). This is not supported by WASM. But JS engines already do it natively, with no overhead for exceptions, until you throw then. With WASM you have to check after each call whether the exception was thrown or not, and that affects performance. * In native environment you can do memory protection magic for different runtime things, e.g. to detect null pointer access, and that's not possible with WASM. * In WASM you can't mutate code, so it makes impossible to implement lazy initialization logic without some overhead. JavaScript engines can detect that certain function got changed and de-optimize calling function, then optimize it again. So, according to my experience and my benchmarks, compiling Java to JavaScript is a better option, both from performance and code size standpoint. WASM team is working on GC and exception handling, but they do it slowly and current design is far from perfect. I failed to convince them to just give access to stack, perhaps in some limited way (for security reasons). And yes, the lack of access to stack even affects C code. For example: int i = 23; foo(&i);

Performs better than most websites which intentionally target JS

chrisco255 8y ago

You mean the DOM. The web isn't slow because of JS.

blotter_paper 8y ago
Slow is relative, and JS is slow relative to WASM.
- rat9988 8y ago
  I can't tell what you are trying to refute in your parent comment.
  - blotter_paper 8y ago
    I'm saying that the web is slow because of JS, not just the DOM (though I'm not contending that the DOM isn't the bigger issue).
    - chrisco255 8y ago
      No its not. JS is extremely fast. The demo above is Java compiled to JS, NOT webassembly.
      - blotter_paper 8y ago
        Again, slow is relative, and JS is slow relative to WASM. That should be obvious, but here's a source.[0] A demo working smoothly does not mean that a language is not slow compared to another. Besides this point, there are some very processing heavy tasks that we're throwing in browsers these days; this demo is not representative of everything we expect browsers to run. And if you read the other comments here, some people were having lag issues with the demo anyway. [0]: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-...
        konsoletyper 8y ago
        No, WASM is slow. As a developer of TeaVM I can claim this. First of all, JS engines been developed for many years, while WASM is a new technology and browser engines don't optimize it well. Another reason is WASM was not designed to run languages like Java, at least in version 1.0. Here are the reasons: * To make GC work properly you have to maintain GC roots. GC roots are static fields + variables in stack. There's no way in WASM to walk the stack! You have to maintain your own shadow stack, losing performance. In case of generating native code (e.g. x86/64) you can access native stack freely and finding GC roots produces no overhead (which is already done by JS engines). * To make exceptions work properly, you need to walk the stack, and not only read it, but also write to it (in case of x86, update RSP direcly). This is not supported by WASM. But JS engines already do it natively, with no overhead for exceptions, until you throw then. With WASM you have to check after each call whether the exception was thrown or not, and that affects performance. * In native environment you can do memory protection magic for different runtime things, e.g. to detect null pointer access, and that's not possible with WASM. * In WASM you can't mutate code, so it makes impossible to implement lazy initialization logic without some overhead. JavaScript engines can detect that certain function got changed and de-optimize calling function, then optimize it again. So, according to my experience and my benchmarks, compiling Java to JavaScript is a better option, both from performance and code size standpoint. WASM team is working on GC and exception handling, but they do it slowly and current design is far from perfect. I failed to convince them to just give access to stack, perhaps in some limited way (for security reasons). And yes, the lack of access to stack even affects C code. For example: int i = 23; foo(&i);