Live data from Hacker News

Is WebAssembly Memory64 worth using?

spidermonkey.dev

21–30 of 55 posts

Re: Is WebAssembly Memory64 worth using?

#21
post #15

Earlier quoted context omitted.

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.

Re: Is WebAssembly Memory64 worth using?

#22
post #6

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…

(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)

Re: Is WebAssembly Memory64 worth using?

#23
post #6

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…

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.

Re: Is WebAssembly Memory64 worth using?

#24
post #15

Earlier quoted context omitted.

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?

[deleted]

Re: Is WebAssembly Memory64 worth using?

#25
post #20

Earlier quoted context omitted.

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.

Re: Is WebAssembly Memory64 worth using?

#26
post #20

Earlier quoted context omitted.

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?

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.

Re: Is WebAssembly Memory64 worth using?

#27
post #5
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 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".

Re: Is WebAssembly Memory64 worth using?

#28
post #3

Love to visit untrusted websites that feel entitled to over 4gb ram without asking.

4 GB VA space. Page tables aren’t that expensive.

The Memory64 proposal is for >4gb space -- and specifically to use it, not just reserve it. Learn context before commenting.

Re: Is WebAssembly Memory64 worth using?

#29
post #3

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]

Re: Is WebAssembly Memory64 worth using?

#30
post #20

Earlier quoted context omitted.

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?

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