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

WASM 3.0 Completed

webassembly.org

Post reply on HN
Print view View original

241–250 of 520 posts

Re: WASM 3.0 Completed

#241

Post by azakai »

cfallin wrote: post #222
re wrote: post #75

I haven't really been following WASM development in the last year and didn't realize that WASM had moved to a versioned release model. I've been aware of the various features in development[1] and had thought many of the newer features were going to remain optional but I guess now that implementations are expected to support all the features to be able to claim compatibility with e.g. "WASM 3.0"? It'll be interesting…

> It'll be interesting to see what the second non-browser-based WASM runtime to fully support 3.0 will be (I'm guessing wasmtime will be first; ...) Wasmtime already supports every major feature in the Wasm 3.0 release, I believe. Of the big ones: garbage collection was implemented by my colleague Nick Fitzgerald a few years ago; tail calls by Jamey Sharp and Trevor Elliott last year (with full generality, any signat…

> garbage collection was implemented by my colleague Nick Fitzgerald a few years ago

The wasm features page says it is still behind a flag on wasmtime (--wasm=gc). Is that page out of date?

Re: WASM 3.0 Completed

#242

Post by jesse__ »

apatheticonion wrote: post #209
cedws wrote: post #180

When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely has anything to do with web anymore. When can we finally kill JavaScript?

Agreed. This and (sane) access to multi-threading. I want to be able to write a Rust application, compile to wasm and load it with Would be great for high performance web applications and for contexts like browser extensions where the memory usage and performance drain is real when multiplied over n open tabs. I'm not sure how code splitting would work in the wasm world, however. v8 could be optimized to reduce its m…

Not sure what the Rust situation is like, but last I checked (and compiled a non-trivial personal application) WASM supported the pthreads API and it seemed to work reasonably well. Have you encountered stumbling points porting a heavily MT Rust program to WASM?

Re: WASM 3.0 Completed

#243

Post by nagisa »

zarzavat wrote: post #234
renehsz wrote: post #97

Earlier quoted context omitted.

Unfortunately, Memory64 comes with a significant performance penalty because the wasm runtime has to check bounds (which wasn't necessary on 32-bit as the runtime would simply allocate the full 4GB of address space every time). But if you really need more than 4GB of memory, then sure, go ahead and use it.

I still don't understand why it's slower to mask to 33 or 34 bit rather than 32. It's all running on 64-bit in the end isn't it? What's so special about 32?

That's because with 32-bit addresses the runtime did not need to do any masking at all. It could allocate a 4GiB area of virtual memory, set up page permissions as appropriate and all memory accesses would be hardware checked without any additional work. Well that, and a special SIGSEGV/SIGBUS handler to generate a trap to the embedder.

With 64-bit addresses, and the requirements for how invalid memory accesses should work, this is no longer possible. AND-masking does not really allow for producing the necessary traps for invalid accesses. So every one now needs some conditional before to validate that this access is in-bounds. The addresses cannot be trivially offset either as they can wrap-around (and/or accidentally hit some other mapping.)

Re: WASM 3.0 Completed

#244

Post by jesse__ »

icar wrote: post #185
cedws wrote: post #180

When is WASM finally going to be able to touch the DOM? It feels like that was the whole point of WASM and instead its become a monster of its own that barely has anything to do with web anymore. When can we finally kill JavaScript?

I would bet on browsers being able to consume Typescript before WASM exposing any DOM API. That'd improve the Javascript situation a bit, at least.

Pretty sure this is here, my dude.

Re: WASM 3.0 Completed

#245

Post by cfallin »

azakai wrote: post #241
cfallin wrote: post #222

Earlier quoted context omitted.

> It'll be interesting to see what the second non-browser-based WASM runtime to fully support 3.0 will be (I'm guessing wasmtime will be first; ...) Wasmtime already supports every major feature in the Wasm 3.0 release, I believe. Of the big ones: garbage collection was implemented by my colleague Nick Fitzgerald a few years ago; tail calls by Jamey Sharp and Trevor Elliott last year (with full generality, any signat…

> garbage collection was implemented by my colleague Nick Fitzgerald a few years ago The wasm features page says it is still behind a flag on wasmtime (--wasm=gc). Is that page out of date?

No, it's still behind a flag (and so transitively, exceptions are too, because we built exception objects on top of GC).

Our docs (https://docs.wasmtime.dev/stability-tiers.html) put GC at tier 2 with reason "production quality" and I believe the remaining concerns there are that we want to do a semi-space copying implementation rather than current DRC eventually. Nick could say more. But we're spec-compliant as-is and the question was whether we've implemented these features -- which we have :-)

Re: WASM 3.0 Completed

#246

Post by [deleted] »

azakai wrote: post #236
zarzavat wrote: post #234

Earlier quoted context omitted.

I still don't understand why it's slower to mask to 33 or 34 bit rather than 32. It's all running on 64-bit in the end isn't it? What's so special about 32?

The special part is the "signal handler trick" that is easy to use for 32-bit pointers. You reserve 4GB of memory - all that 32 bits can address - and mark everything above used memory as trapping. Then you can just do normal reads and writes, and the CPU hardware checks out of bounds. With 64-bit pointers, you can't really reserve all the possible space a pointer might refer to. So you end up doing manual bounds che…

[deleted]

Re: WASM 3.0 Completed

#247

Post by tracker1 »

saulpw wrote: post #227
brokencode wrote: post #215

Earlier quoted context omitted.

You can use a framework that abstracts all the WASM to JS communication for DOM access. There are many such framework already. The only issue is that there’s a performance cost. Not sure how significant it is for typical applications, but it definitely exists. It’d be nice to have direct DOM access, but if the performance is not a significant problem, then I can see the rationale for not putting in the major amount o…

Which framework is the best or most commonly used?

Yew, Leptos and Dioxus are all pretty decent with their own advantages and disadvantages if you like Rust. It's been a year or so since I last looked at them, to me the biggest missing piece was a component library along the lines of MUI to build useful things with. I'd be surprised if there weren't at least Bootstrap compatible wrapper libraries for them at this point.

Re: WASM 3.0 Completed

#248

Post by azakai »

alabhyajindal wrote: post #123

The WebAssembly community should really focus more the developer experience of using it. I recently completed a project where I wrote a compiler¹ targeting it and found the experience to be rather frustrating. Given that Wasm is designed with formal semantics in mind, why is the DX of using it as a target so bad? I used binaryen.js to emit Wasm in my compiler and didn't get a feeling that I am targeting a well design…

Sorry about binaryen.js - those JS/TS bindings could be a lot better, and better documented, but priorities are generally focused on improving optimizations in core Binaryen.

That is, most work in Binaryen is on improving wasm-opt which inputs wasm and outputs wasm, so any toolchain can use it (as opposed to just JS/TS).

But if someone had the time to improve the JS/TS bindings that would be great!

Re: WASM 3.0 Completed

#249

Post by azakai »

cfallin wrote: post #245
azakai wrote: post #241

Earlier quoted context omitted.

> garbage collection was implemented by my colleague Nick Fitzgerald a few years ago The wasm features page says it is still behind a flag on wasmtime (--wasm=gc). Is that page out of date?

No, it's still behind a flag (and so transitively, exceptions are too, because we built exception objects on top of GC). Our docs ( https://docs.wasmtime.dev/stability-tiers.html ) put GC at tier 2 with reason "production quality" and I believe the remaining concerns there are that we want to do a semi-space copying implementation rather than current DRC eventually. Nick could say more. But we're spec-compliant as-is…

Great, thanks for the info!

Re: WASM 3.0 Completed

#250

Post by tracker1 »

fidotron wrote: post #205
bborud wrote: post #65

I'm a simple man who has simple needs. I want a better and faster way to pass Go structs in and out of the runtime that doesn't mean I have to do a sword dance on a parquet floor wearing thick knit wool socks and use some fragile grafted on solution. If there can be a solution that works for more languages: great. I mostly want this for Go. If it means there will be some _reasonable_ limitations, that's also fine.

This is the truth, and it's not really much better in non-GCed languages either. (In reality my impression is the GCed wasm side runtimes are even worse). Some of the least fun JavaScript I have ever written involved manually cleaning up pointers that in C++ would be caught by destructors triggering when the variable falls out of scope. It was enough that my recollections of JNI were more tolerable. (Including for go…

Was this dealing with DOM nodes and older IE versions by chance? That was probably the single biggest reason to wrap all DOM manipulation with JQuery in that it did a decent job of tracking and cleanup for you. IIRC, a lot of the issues came from the DOM and JS being in separate COM areas and the bridge not really tracking connections for both sides.
Post reply on HN