Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is WebAssembly Memory64 worth using?

spidermonkey.dev

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Is WebAssembly Memory64 worth using?

#41

Post by mort96 »

flohofwoe wrote: post #35
mwkaufma wrote: post #30

Earlier quoted context omitted.

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

Re: Is WebAssembly Memory64 worth using?

#42

Post by TekMol »

flohofwoe wrote: post #36
TekMol wrote: post #31

Earlier quoted context omitted.

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?

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'. Wi…

Are you saying JavaScript is not turing complete, so it can't do everything that other languages can?

Re: Is WebAssembly Memory64 worth using?

#43

Post by pjmlp »

TekMol wrote: post #27
pjmlp wrote: post #5

Earlier quoted context omitted.

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: code = `( func $add (param $a i32) (param $b i32) (result i32) local.get $a local.get $b i32.add )`; module = WebAssembly.compile(code); alert(module.add(3, 5)); // alerts "8".

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.

Re: Is WebAssembly Memory64 worth using?

#44

Post by noelwelsh »

TekMol wrote: post #31
flohofwoe wrote: post #19

Earlier quoted context omitted.

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?

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.

Re: Is WebAssembly Memory64 worth using?

#45

Post by meheleventyone »

TekMol wrote: post #31
flohofwoe wrote: post #19

Earlier quoted context omitted.

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.

Re: Is WebAssembly Memory64 worth using?

#46

Post by flohofwoe »

TekMol wrote: post #42
flohofwoe wrote: post #36

Earlier quoted context omitted.

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'. Wi…

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.

Re: Is WebAssembly Memory64 worth using?

#47

Post by rav »

TekMol wrote: post #4

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.

Re: Is WebAssembly Memory64 worth using?

#48

Post by flohofwoe »

noelwelsh wrote: post #44
TekMol wrote: post #31

Earlier quoted context omitted.

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?

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.

Re: Is WebAssembly Memory64 worth using?

#49

Post by TekMol »

rav wrote: post #47
TekMol wrote: post #4

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…

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.

Re: Is WebAssembly Memory64 worth using?

#50

Post by masklinn »

sirwhinesalot wrote: post #16
TekMol wrote: post #15

Earlier quoted context omitted.

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?

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.
Post reply on HN