3 ms·

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

by 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...
noelwelsh 2y ago
Speed is not fine. It's good enough for a lot of apps, but it doesn't get the job done for anything performance sensitive. An obvious issue is the lack of real machine number types, which makes anything numeric much slower than it could be. Furthermore, JS semantics are limiting in other respects. E.g. there are people looking at tail calls and continuations in WebAssembly, which I can't see ever coming to JS.
- flohofwoe 2y ago
  > An obvious issue is the lack of real machine number types This was basically what the special asm.js support in JS engines was about (via "use asm") and brought performance to about WASM level. IIRC this special asm.js support brought a 2x to 3x performance advantage (e.g. running asm.js in Chrome/Firefox which both had special asm.js support vs Safari which didn't). AFAIK the initial WASM implementation in browsers was more or less an evolution of that asm.js special-path.
meheleventyone 2y ago
People can use software written in languages that need a compile target. For example you can write web applications that use libraries written in C/C++ that before would have needed to be hand ported to JS or compiled using technology like asmjs that was creaking at the seams. From the user perspective it enables more rich web applications. From a performance perspective it's also a different target for web engines so has different opportunities for optimization. It's not clear to me we've reached the limit on that at the moment, or how much work browser developers are putting in to optimizing their WASM codepaths. The standard also includes support for things like SIMD which is not natively available in JS land which should provice a boost for suitable workloads and there is a lot coming through the proposal pipeline (https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals) that will also let WASM diverge more from JS. From a developer perspective allowing more languages than JS also has some productivity benefits. Both in using languages they are more familiar with and those better suited to certain domains. For example you can write math code in JS, in particular making use of TypedArrays to help things along but its much more straightforward in a language that supports more 'native' types.

by 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...

noelwelsh 2y ago

Speed is not fine. It's good enough for a lot of apps, but it doesn't get the job done for anything performance sensitive. An obvious issue is the lack of real machine number types, which makes anything numeric much slower than it could be. Furthermore, JS semantics are limiting in other respects. E.g. there are people looking at tail calls and continuations in WebAssembly, which I can't see ever coming to JS.

flohofwoe 2y ago
> An obvious issue is the lack of real machine number types This was basically what the special asm.js support in JS engines was about (via "use asm") and brought performance to about WASM level. IIRC this special asm.js support brought a 2x to 3x performance advantage (e.g. running asm.js in Chrome/Firefox which both had special asm.js support vs Safari which didn't). AFAIK the initial WASM implementation in browsers was more or less an evolution of that asm.js special-path.

meheleventyone 2y ago

People can use software written in languages that need a compile target. For example you can write web applications that use libraries written in C/C++ that before would have needed to be hand ported to JS or compiled using technology like asmjs that was creaking at the seams. From the user perspective it enables more rich web applications. From a performance perspective it's also a different target for web engines so has different opportunities for optimization. It's not clear to me we've reached the limit on that at the moment, or how much work browser developers are putting in to optimizing their WASM codepaths. The standard also includes support for things like SIMD which is not natively available in JS land which should provice a boost for suitable workloads and there is a lot coming through the proposal pipeline (https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals) that will also let WASM diverge more from JS. From a developer perspective allowing more languages than JS also has some productivity benefits. Both in using languages they are more familiar with and those better suited to certain domains. For example you can write math code in JS, in particular making use of TypedArrays to help things along but its much more straightforward in a language that supports more 'native' types.