Looking forward to progress on the memory control proposal(s).
Another reason to want more than 4GB of memory is to have more address space, assuming that you have the ability to map it. With that capability Wasm64 could be useful also for apps that don't plan to use a huge amount for real.
Yes, this is my primary personal motivator as co-champion of the proposal. But, going “fully virtual” is hard because of the very wide array of use cases for wasm.
For example, there are embedded users of wasm whose devices don’t even have MMUs. And even when running on a device with an MMU, the host may not want to allow arbitrary mappings, e.g. if using wasm as a plugin system in a database or something.
It’s likely imo that any “fully virtual” features will be part of the wasm web API and not the core spec, if they happen at all.
ARM already have a special instruction `FJCVTZS` to accelerate JavaScript. If WebAssembly gets popular enough there will probably be hardware acceleration for it.
JavaScript is in the name, but really it's just a way to convert floats to ints with the kind of rounding that x86 does. The impetus might've been to run JS faster because JS specifies x86 semantics, but it's not like it's some wild "JavaScript acceleration instruction". I don't really get why they put JavaScript in the name to be honest.
Except FJCVTZS is not exclusively useful to javascript. Its behaviour is that of x86 rounding, which is what the JS spec encodes. So it’s also useful for x86 emulation / compatibility in general.
> If WebAssembly gets popular enough there will probably be hardware acceleration for it.
ARM already tried that back in the days with Jazelle. Plus much of the point of WASM is that you can compile it to machine code during loading.
The reason I don't use WebAssembly is that browsers do not support the text format.
Often it is just a tiny loop that one wants to optimize. Writing it manually in WAT would be nice. But adding a whole toolchain and a compile step to the stack is not worth it.
Shouldn't it be straight forward to compile WAT to WASM? I hope one day browsers will support it.
You could use handwritten asmjs in that case. I did it at work to improve performance on some pixel-wise software rendering we were doing. (We have since then switched to WebGL, but asmjs was a nice stepping stone.) If I recall correctly, it basically boils down to using small fixed size arrays and appending "|0" after each uint32 operation and "+" in front of each float32 operation - so it's something you can do by hand. Of course, one of my colleagues then made a tweak which gave a surprisingly huge slowdown - you should probably declare loudly (with comments etc.) that a certain code block is intended to be asmjs if you do this in a large codebase.
asmjs is great. Imho the better approach than wasm. But it seems to not have great browser support (no Safari for example). And support is probably not getting better in the future.
[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.
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?
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.
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?
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]
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.
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?
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) 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.
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.
Are you saying JavaScript is not turing complete, so it can't do everything that other languages can?
Turing complete doesn't say anything about runtime performance or compile times.
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?
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
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...
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.
> 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.
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.
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.
You can do that easily with binaryen already, and make use of parseText().
Which you can get by making use of binaren.js library already, so you won't get any browser vendor love to include the feature into the browsers directly.
"How do browsers take advantage of this fact? By reserving 4GB of memory for every single WebAssembly module."
Does reserve mean it has exclusive access to? Because it can't possibly be that every single wasm module takes 4GB!
It's allocating 4 GB out of the virtual address space, not 4 GB of physical memory.
It's really reserving 4GB of the process's own address space, but the only part of it that physical memory has to get used for is the part that actually has stuff stored in it.
Love to visit untrusted websites that feel entitled to over 4gb ram without asking.
That's virtual address space, not physical RAM. E.g. (if my math is correct) 0.0015 percent of the available space per WASM process. I think that's acceptable ;)
[flagged]
4 GB VA space. Page tables aren’t that expensive.
Isn't the whole reason they're adding 64 bit addresses to support websites which want to use over 4GiB? What other reason could there be?
The website may want to, but I don't.
Yes, but think of DCC applications like Figma which might run into the 4 GB restriction with large data sets, not regular websites which run a couple of WebGL demos written in C.
...also WASM is starting to become popular outside the browser where requirements might be very different from running stuff in webpages.
Let figma ask me for explicit permission first, then, as opposed to making Memory64 support implicitly available.
...what's different than running any other application that uses more than 4 GB RAM on your computer, and why exactly 4 GB and not any other number? You can easily check the per-page memory footprint in Chrome's task manager and decide not to use such 'memory hogs'.
Apps don't suddenly start running just from clicking a link, the relationship with websites is inherently adversarial while the relationship with apps is typically not
The Memory64 proposal is for >4gb space -- and specifically to use it, not just reserve it. Learn context before commenting.
On the flip side, it would do you well to read this: https://news.ycombinator.com/newsguidelines.html. As for the actual content of your comment, pages already have access to more than 4 GB of RAM. It's actually quite easy to do just from JavaScript.
Yeah, I hate that JS can do it too. Website bloat is a problem we should be fixing, not accepting. Have you tried to browse the web on a "budget laptop" lately?
Unless you want to install a crypto miner to run locally on someone's machine when they visit a website.
Now possible with this as well as even more capable closed-source untrusted binary blobs with DRM running amock on your machine.
Mozilla (a member part of the W3C) and was supposed to stop such DRM-like software from reaching the web. They have proven to be powerless to allow such software like this to be approved as a web standard.
The ones cheering WASM are the ones who absolutely love DRM and malware blobs in your machine now accessible in the browser.
This is a massive failure of the so-called "Open Web".
Crypto miners written in JS existed long before WebAssembly. Back then people also compiled large C++ code bases to (highly obfuscated) JS code and out of these heroic efforts grew asm.js which then evolved to WebAssembly. WebAssembly is a much better compile target than JS with more low-level types and primitives, but it's very similar to JS code in what it can and can't do in the browser.
Compiling a C++ application to megabytes of JS code doesn't make the result any more open-source or non-DRM than compiling the same thing to WebAssembly (you could translate Wasm to the equivalent but slower JS code).
DRM? That's news to me, the only DRM I was aware of in the web was EME. Can you elaborate?
Or are you just using a different definition of "DRM" to the rest of us, where your definition is "binary format == DRM"?
FWIW I know plenty of people who are excited about WASM because it + WebGPU/WebGL allows them to put their (sometimes open source) games on a website. "The ones cheering WASM are people who push DRM" is patently and obviously false.
(1) WASM can be blocked with regular ad-blockers (just like JS)
(2) you can't do anything in WASM that you can't also do in JS (and the performance difference is hardly noticeable either for well-optimized JS)
TL;DR: no, unless you actually need more than 32-bit address range. The other advantages of 64-bit CPUs (e.g. 64-bit integer registers, more general purpose registers) are already taken advantage of by wasm32.
Looking forward to progress on the memory control proposal(s). Another reason to want more than 4GB of memory is to have more address space, assuming that you have the ability to map it. With that capability Wasm64 could be useful also for apps that don't plan to use a huge amount for real.
Yes, this is my primary personal motivator as co-champion of the proposal. But, going “fully virtual” is hard because of the very wide array of use cases for wasm.
For example, there are embedded users of wasm whose devices don’t even have MMUs. And even when running on a device with an MMU, the host may not want to allow arbitrary mappings, e.g. if using wasm as a plugin system in a database or something.
It’s likely imo that any “fully virtual” features will be part of the wasm web API and not the core spec, if they happen at all.
ARM already have a special instruction `FJCVTZS` to accelerate JavaScript. If WebAssembly gets popular enough there will probably be hardware acceleration for it.
https://community.arm.com/arm-community-blogs/b/architecture...
https://stackoverflow.com/questions/50966676/why-do-arm-chip...
JavaScript is in the name, but really it's just a way to convert floats to ints with the kind of rounding that x86 does. The impetus might've been to run JS faster because JS specifies x86 semantics, but it's not like it's some wild "JavaScript acceleration instruction". I don't really get why they put JavaScript in the name to be honest.
Except FJCVTZS is not exclusively useful to javascript. Its behaviour is that of x86 rounding, which is what the JS spec encodes. So it’s also useful for x86 emulation / compatibility in general.
> If WebAssembly gets popular enough there will probably be hardware acceleration for it.
ARM already tried that back in the days with Jazelle. Plus much of the point of WASM is that you can compile it to machine code during loading.
The reason I don't use WebAssembly is that browsers do not support the text format.
Often it is just a tiny loop that one wants to optimize. Writing it manually in WAT would be nice. But adding a whole toolchain and a compile step to the stack is not worth it.
Shouldn't it be straight forward to compile WAT to WASM? I hope one day browsers will support it.
You could use handwritten asmjs in that case. I did it at work to improve performance on some pixel-wise software rendering we were doing. (We have since then switched to WebGL, but asmjs was a nice stepping stone.) If I recall correctly, it basically boils down to using small fixed size arrays and appending "|0" after each uint32 operation and "+" in front of each float32 operation - so it's something you can do by hand. Of course, one of my colleagues then made a tweak which gave a surprisingly huge slowdown - you should probably declare loudly (with comments etc.) that a certain code block is intended to be asmjs if you do this in a large codebase.
asmjs is great. Imho the better approach than wasm. But it seems to not have great browser support (no Safari for example). And support is probably not getting better in the future.
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.
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?
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.
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?
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-...
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).
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.
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?
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) 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.
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.
Are you saying JavaScript is not turing complete, so it can't do everything that other languages can?
Turing complete doesn't say anything about runtime performance or compile times.
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?
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
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...
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.
> 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.
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.
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.
You can do that easily with binaryen already, and make use of parseText().
https://web.dev/articles/binaryen
Not sure what you mean. I guess this is a misunderstanding.
What I mean is that I would like something like this to work:
The WebAssembly reference interpreter [0] has a JS library that lets you do this.
[0] https://github.com/WebAssembly/spec/tree/main/interpreter#ja...Which you can get by making use of binaren.js library already, so you won't get any browser vendor love to include the feature into the browsers directly.
"How do browsers take advantage of this fact? By reserving 4GB of memory for every single WebAssembly module."
Does reserve mean it has exclusive access to? Because it can't possibly be that every single wasm module takes 4GB!
It's allocating 4 GB out of the virtual address space, not 4 GB of physical memory.
It's really reserving 4GB of the process's own address space, but the only part of it that physical memory has to get used for is the part that actually has stuff stored in it.
Love to visit untrusted websites that feel entitled to over 4gb ram without asking.
That's virtual address space, not physical RAM. E.g. (if my math is correct) 0.0015 percent of the available space per WASM process. I think that's acceptable ;)
[flagged]
4 GB VA space. Page tables aren’t that expensive.
Isn't the whole reason they're adding 64 bit addresses to support websites which want to use over 4GiB? What other reason could there be?
The website may want to, but I don't.
Yes, but think of DCC applications like Figma which might run into the 4 GB restriction with large data sets, not regular websites which run a couple of WebGL demos written in C.
...also WASM is starting to become popular outside the browser where requirements might be very different from running stuff in webpages.
Let figma ask me for explicit permission first, then, as opposed to making Memory64 support implicitly available.
...what's different than running any other application that uses more than 4 GB RAM on your computer, and why exactly 4 GB and not any other number? You can easily check the per-page memory footprint in Chrome's task manager and decide not to use such 'memory hogs'.
Apps don't suddenly start running just from clicking a link, the relationship with websites is inherently adversarial while the relationship with apps is typically not
The Memory64 proposal is for >4gb space -- and specifically to use it, not just reserve it. Learn context before commenting.
On the flip side, it would do you well to read this: https://news.ycombinator.com/newsguidelines.html. As for the actual content of your comment, pages already have access to more than 4 GB of RAM. It's actually quite easy to do just from JavaScript.
Yeah, I hate that JS can do it too. Website bloat is a problem we should be fixing, not accepting. Have you tried to browse the web on a "budget laptop" lately?
Unless you want to install a crypto miner to run locally on someone's machine when they visit a website.
Now possible with this as well as even more capable closed-source untrusted binary blobs with DRM running amock on your machine.
Mozilla (a member part of the W3C) and was supposed to stop such DRM-like software from reaching the web. They have proven to be powerless to allow such software like this to be approved as a web standard.
The ones cheering WASM are the ones who absolutely love DRM and malware blobs in your machine now accessible in the browser.
This is a massive failure of the so-called "Open Web".
Crypto miners written in JS existed long before WebAssembly. Back then people also compiled large C++ code bases to (highly obfuscated) JS code and out of these heroic efforts grew asm.js which then evolved to WebAssembly. WebAssembly is a much better compile target than JS with more low-level types and primitives, but it's very similar to JS code in what it can and can't do in the browser.
Compiling a C++ application to megabytes of JS code doesn't make the result any more open-source or non-DRM than compiling the same thing to WebAssembly (you could translate Wasm to the equivalent but slower JS code).
DRM? That's news to me, the only DRM I was aware of in the web was EME. Can you elaborate?
Or are you just using a different definition of "DRM" to the rest of us, where your definition is "binary format == DRM"?
FWIW I know plenty of people who are excited about WASM because it + WebGPU/WebGL allows them to put their (sometimes open source) games on a website. "The ones cheering WASM are people who push DRM" is patently and obviously false.
(1) WASM can be blocked with regular ad-blockers (just like JS)
(2) you can't do anything in WASM that you can't also do in JS (and the performance difference is hardly noticeable either for well-optimized JS)
TL;DR: no, unless you actually need more than 32-bit address range. The other advantages of 64-bit CPUs (e.g. 64-bit integer registers, more general purpose registers) are already taken advantage of by wasm32.