3 ms·

Chances are that you won't get much out of WASM for such small snippets anyway. Contrary to popular belief, well-written Javascript isn't drastically slower tha

Chances are that you won't get much out of WASM for such small snippets anyway. Contrary to popular belief, well-written Javascript isn't drastically slower than WASM in most situations.

TekMol 2y ago
Then why does WASM exist? If someone wants to compile whatever other language to run in the browser, why not just compile it to well-written JavaScript?
- sirwhinesalot 2y ago
  We used to have asm.js for that. For various reasons wasm is a replacement for it. JS doesn't even have proper integer types, it is not a good target language.
  - masklinn 2y ago
    asmjs had an i32 type by (ab)using JS semantics and a common jit optimisation: bitwise ops are defined for 32 bits two’s complement integer. So x|0 necessarily results in an i32.
- flohofwoe 2y ago
  Simple: Javascript can focus on being a human-friendly programming language, while WASM can focus on being a compile target. If you've been around in the asm.js times, this conflict was a real concern.
  - TekMol 2y ago
    That does not answer the question what the benefit of compiling to WASM rather than to JavaScript is. If speed is fine, why would I care if a compiler compiled to a human-friendly language?
    - flohofwoe 2y ago
      Because Javascript would need to change a lot to better support compiled languages (for instance adding 'proper' separate integer and float types, but that's just the tip of the iceberg). This means extending the ECMAScript standard with features only few web developers care about, increased complexity in JS engines, and potential design-conflicts for new JS features between 'compile-friendly' vs 'human-friendly'. With WASM, the WASM peeps can focus on WASM and the JS peeps can focus on JS.
      - TekMol 2y ago
        Are you saying JavaScript is not turing complete, so it can't do everything that other languages can?
        flohofwoe 2y ago
        Turing complete doesn't say anything about runtime performance or compile times.
        reductum 2y ago
        I haven't used asm.js and compared it to WASM myself, so I'm curious to understand your statements here. Regarding runtime performance, you said "Javascript isn't drastically slower than WASM in most situations." So are you saying that the reason WASM exists is to have faster compile times than asm.js, or marginally faster runtime perf in most situations, or drastically faster runtime perf in rare situations?
        flohofwoe 2y ago
        There's a couple of different sides to the story: - Both WASM and asm.js don't incur JS garbage collector overhead, but it's also possible to write (mostly) garbage-free Javascript by hand. - Both WASM and asm.js don't use Javascript objects or strings (only numbers), and especially not JS objects where the interior structure changes randomly - which in turn might cause JIT recompiles, but it's also possible to write such 'static' Javascript by hand, especially when using Typescript. That's basically about the claim 'Javascript performance can be close to WASM'. It's possible to write JS manually which is 'optimization-friendly', but is not necessarily idiomatic JS - the extreme version of this optimization-friendly JS is asm.js, but nobody would want to write that by hand. Then of course WASM pushes the optimization wall a bit further then what's possible with JS, which may increase the performance gap in very specific situations: - WASM has native 64-bit integers (JS has BigInt now, but I don't know if they optimize as well under the hood) - modern WASM has SIMD instructions, which was once an ECMAScript proposal, but has been abandondend in favour of WASM SIMD: https://github.com/tc39/ecmascript_simd https://github.com/tc39/ecmascript_simd Finally there's the historical angle (e.g. "why does WASM exist in the first place"): TL;DR: - with the end of native plugins, Java and Flash in the browser, people were looking for new alternatives to Javascript in the browser - around 2008(?) Emscripten demonstrated that compiling C/C++ to a subset of Javascript can give surprisingly good performance - this subset was then formalized into asm.js and browsers started to add specific optimizations for that subset (via "use asm") - but this JS subset was a dead-end in the long run because requirements for a "Javascript-as-compile-target" clashed more and more with "Javascript-as-programming-language" - ...so a split was made and WASM was created, from now on, Javascript could focus again to be a programming language, and WASM could focus on being a compile target I guess that's it...
- masklinn 2y ago
  Mozilla tried that with asmjs. Turns out javascript has pretty half-assed semantics (notably around integer types), nobody wants to expand it to a useful compilation (asmjs was mostly an optimisation for hand-written code) target, and few want to compile to text, especially javascript. Having a proper and well defined ISA is a lot more compelling. Not only that, but it allows WASM-only compilers and runtimes with none of the JS baggage, and thus use of WASM outside of a browser context and with significantly lower resources requirements.
  - TekMol 2y ago
    That makes it sound like WASM only exists because of the nerdy preferences of compiler makers, not because of any benefits to the users of applications? If speed is fine, why would a user care if the application was compiled to a language with "half-assed semantics" in a text format?
    - mort96 2y ago
      I don't think speed is fine. Here's a write-up from Mozilla which talks about the performance benefits of WASM compared to asm.js: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-...
      - flohofwoe 2y ago
        FWIW, switching from asm.js to wasm in was hardly noticeable performance-wise for my code (at least in browsers that already had a special 'fast-path' for asm.js).
- deleted 2y ago
  [deleted]

Chances are that you won't get much out of WASM for such small snippets anyway. Contrary to popular belief, well-written Javascript isn't drastically slower than WASM in most situations.

TekMol 2y ago

Then why does WASM exist? If someone wants to compile whatever other language to run in the browser, why not just compile it to well-written JavaScript?

sirwhinesalot 2y ago
We used to have asm.js for that. For various reasons wasm is a replacement for it. JS doesn't even have proper integer types, it is not a good target language.
- masklinn 2y ago
  asmjs had an i32 type by (ab)using JS semantics and a common jit optimisation: bitwise ops are defined for 32 bits two’s complement integer. So x|0 necessarily results in an i32.
flohofwoe 2y ago
Simple: Javascript can focus on being a human-friendly programming language, while WASM can focus on being a compile target. If you've been around in the asm.js times, this conflict was a real concern.
- TekMol 2y ago
  That does not answer the question what the benefit of compiling to WASM rather than to JavaScript is. If speed is fine, why would I care if a compiler compiled to a human-friendly language?
  - flohofwoe 2y ago
    Because Javascript would need to change a lot to better support compiled languages (for instance adding 'proper' separate integer and float types, but that's just the tip of the iceberg). This means extending the ECMAScript standard with features only few web developers care about, increased complexity in JS engines, and potential design-conflicts for new JS features between 'compile-friendly' vs 'human-friendly'. With WASM, the WASM peeps can focus on WASM and the JS peeps can focus on JS.
    - TekMol 2y ago
      Are you saying JavaScript is not turing complete, so it can't do everything that other languages can?
      - flohofwoe 2y ago
        Turing complete doesn't say anything about runtime performance or compile times.
        reductum 2y ago
        I haven't used asm.js and compared it to WASM myself, so I'm curious to understand your statements here. Regarding runtime performance, you said "Javascript isn't drastically slower than WASM in most situations." So are you saying that the reason WASM exists is to have faster compile times than asm.js, or marginally faster runtime perf in most situations, or drastically faster runtime perf in rare situations?
        flohofwoe 2y ago
        There's a couple of different sides to the story: - Both WASM and asm.js don't incur JS garbage collector overhead, but it's also possible to write (mostly) garbage-free Javascript by hand. - Both WASM and asm.js don't use Javascript objects or strings (only numbers), and especially not JS objects where the interior structure changes randomly - which in turn might cause JIT recompiles, but it's also possible to write such 'static' Javascript by hand, especially when using Typescript. That's basically about the claim 'Javascript performance can be close to WASM'. It's possible to write JS manually which is 'optimization-friendly', but is not necessarily idiomatic JS - the extreme version of this optimization-friendly JS is asm.js, but nobody would want to write that by hand. Then of course WASM pushes the optimization wall a bit further then what's possible with JS, which may increase the performance gap in very specific situations: - WASM has native 64-bit integers (JS has BigInt now, but I don't know if they optimize as well under the hood) - modern WASM has SIMD instructions, which was once an ECMAScript proposal, but has been abandondend in favour of WASM SIMD: https://github.com/tc39/ecmascript_simd https://github.com/tc39/ecmascript_simd Finally there's the historical angle (e.g. "why does WASM exist in the first place"): TL;DR: - with the end of native plugins, Java and Flash in the browser, people were looking for new alternatives to Javascript in the browser - around 2008(?) Emscripten demonstrated that compiling C/C++ to a subset of Javascript can give surprisingly good performance - this subset was then formalized into asm.js and browsers started to add specific optimizations for that subset (via "use asm") - but this JS subset was a dead-end in the long run because requirements for a "Javascript-as-compile-target" clashed more and more with "Javascript-as-programming-language" - ...so a split was made and WASM was created, from now on, Javascript could focus again to be a programming language, and WASM could focus on being a compile target I guess that's it...
masklinn 2y ago
Mozilla tried that with asmjs. Turns out javascript has pretty half-assed semantics (notably around integer types), nobody wants to expand it to a useful compilation (asmjs was mostly an optimisation for hand-written code) target, and few want to compile to text, especially javascript. Having a proper and well defined ISA is a lot more compelling. Not only that, but it allows WASM-only compilers and runtimes with none of the JS baggage, and thus use of WASM outside of a browser context and with significantly lower resources requirements.
- TekMol 2y ago
  That makes it sound like WASM only exists because of the nerdy preferences of compiler makers, not because of any benefits to the users of applications? If speed is fine, why would a user care if the application was compiled to a language with "half-assed semantics" in a text format?
  - mort96 2y ago
    I don't think speed is fine. Here's a write-up from Mozilla which talks about the performance benefits of WASM compared to asm.js: https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-...
    - flohofwoe 2y ago
      FWIW, switching from asm.js to wasm in was hardly noticeable performance-wise for my code (at least in browsers that already had a special 'fast-path' for asm.js).
deleted 2y ago
[deleted]