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

51–55 of 55 posts

Re: Is WebAssembly Memory64 worth using?

#51

Post by reductum »

flohofwoe wrote: post #46
TekMol wrote: post #42

Earlier quoted context omitted.

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?

Re: Is WebAssembly Memory64 worth using?

#52

Post by bvisness »

yuri91 wrote: post #38

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.

Re: Is WebAssembly Memory64 worth using?

#53

Post by flohofwoe »

reductum wrote: post #51
flohofwoe wrote: post #46

Earlier quoted context omitted.

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

Re: Is WebAssembly Memory64 worth using?

#54

Post by mwkaufma »

saagarjha wrote: post #40
mwkaufma wrote: post #28

Earlier quoted context omitted.

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?

Re: Is WebAssembly Memory64 worth using?

#55

Post by saagarjha »

mwkaufma wrote: post #54
saagarjha wrote: post #40

Earlier quoted context omitted.

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?

I don't think "here is technology to let websites address more RAM" is the cause of web bloat.
Post reply on HN