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

31–40 of 520 posts

Re: WASM 3.0 Completed

#31

Post by onionisafruit »

bryanlarsen wrote: post #23
em-bee wrote: post #16

Earlier quoted context omitted.

how is that different from compiling against a traditional CPU which also doesn't have a built in GC? i mean those programs that need a GC already have one. so what is the benefit of including one on the "CPU"?

The fact that a minimum size go program is a few megabytes in size is acceptable in most places in 2025. If it was shipped over the wire for every run time instead of a single install time download, that would be a different story. Garbage collection is a small part of the go run time, but it's not insignificant.

I will be interested to see if Go is able to make use of this GC and if so, how much that wasm binaries

Re: WASM 3.0 Completed

#33

Post by flohofwoe »

Since it hasn't been mentioned here yet: I wonder if the multiple-memories feature will somehow allow to avoid the extra copy that's currently needed when mapping a WebGPU resource. This mapping is available in a separate ArrayBuffer object which isn't accessible from WASM without calling into JS and then copying from the ArrayBuffer into the WASM heap and back.

Multiple WASM memories and Clang's/LLVM's address space feature sound like they should be able to solve that problem, but I'm not sure if it is as trivial as it sounds...

Re: WASM 3.0 Completed

#34

Post by phickey »

pbiswal wrote: post #18

Is the component model work ( https://component-model.bytecodealliance.org/ ) related to the 3.0 release in any way?

No, the component model proposal is not part of the Wasm 3.0 release. Proposals only make it into a Wasm point release once they reach stage 5, and the component model is still under development and so is not trying to move through the phases yet.

Unlike any of the proposals which became part of Wasm 3.0, the component model does not make any changes to the core Wasm module encoding or its semantics. Instead, it’s designed as a new encoding container which contain core Wasm modules, and adds extra information alongside each module describing its interface types and how to instantiate and link those modules. By keeping all of these additions outside of core Wasm, we can build implementations out of any plain old Wasm engine, plus extra code that instantiates and links those modules, and converts between the core wasm ABI to higher level interface types. The Jco project https://github.com/bytecodealliance/jco does exactly that using the common JS interface used by every web engine’s Wasm implementation. So, we can ship the component model on the web without web engines putting in any work of their own, which isn’t possible with proposals which add or change core wasm.

Re: WASM 3.0 Completed

#36

Post by phickey »

ridiculous_fish wrote: post #11
aag wrote: post #8

Earlier quoted context omitted.

Not including GC would have been a mistake. Having to carry a complete garbage collector with every program, especially on platforms like browsers were excellent ones already exist, would have been a waste.

Doesn't every WASM program have to carry its own malloc/free today?

Yes, every wasm program that uses linear memory (which includes all those created by llvm toolchains) must ship with its own allocator. You only get to use the wasm GC provided allocator if your program is using the gc types, which can’t be stored in a linear memory.

Re: WASM 3.0 Completed

#37

Post by nu11ptr »

kg wrote: post #5
jsheard wrote: post #2

Has anyone benchmarked 64bit memory on the current implementations? There's the potential for performance regressions there because they could exploit the larger address space of 64bit hosts to completely elide bounds checks when running 32bit WASM code, but that doesn't work if the WASM address space is also 64bit.

> WebAssembly apps tend to run slower in 64-bit mode than they do in 32-bit mode. This performance penalty depends on the workload, but it can range from just 10% to over 100%—a 2x slowdown just from changing your pointer size. > This is not simply due to a lack of optimization. Instead, the performance of Memory64 is restricted by hardware, operating systems, and the design of WebAssembly itself. https://spidermonke…

Is this WASM specific though? Some apps suffer in performance when they move to 64-bit in general due to larger pointers and not taking sufficient advantage of/or needing 64-bit data types in general, hence the increased memory bandwidth/cache space slows them down (one of the reasons many people like a 32-bit address space, 64-bit data model).

Re: WASM 3.0 Completed

#38

Post by flohofwoe »

ridiculous_fish wrote: post #11
aag wrote: post #8

Earlier quoted context omitted.

Not including GC would have been a mistake. Having to carry a complete garbage collector with every program, especially on platforms like browsers were excellent ones already exist, would have been a waste.

Doesn't every WASM program have to carry its own malloc/free today?

Yes, but Emscripten comes with a minimal allocator that's good enough for most C code (e.g. code with low alloc/free frequency) and only adds minimal size overhead:

https://github.com/emscripten-core/emscripten/blob/main/syst...

Re: WASM 3.0 Completed

#39

Post by dzaima »

WhereIsTheTruth wrote: post #6

> GC and Exception handling This was not necessary.. what a mistake, specially EH..

Besides making it much nicer for GC'd languages to target WASM, an important aspect is that it also allows cross-language GC.

Whereas with a manual GC, if you had a JS object holding a reference to an object on your custom heap, and your heap holds a reference to that JS object (with indirections sprinkled in to taste) but nothing else references it, that'd result in a permanent memory leak, as both heaps would have to consider everything held by the other as GC roots; so you'd still be forced to manually avoid cycles despite only ever using GC'd languages. Wasm GC entirely avoids this problem.

Re: WASM 3.0 Completed

#40

Post by 0x457 »

em-bee wrote: post #25
aag wrote: post #17

Earlier quoted context omitted.

The "CPU" in every browser already has one. This lets garbage-collected languages use that one. That's an enormous savings in code size and development effort.

i don't see the reduced development effort, after all, unless the language is only running on webassembly i still need to implement my own GC for other CPUs. so most GC-languages being ported to webassembly already have a GC, so what is the benefit of using a provided GC then? on the other hand i see GC as a feature that could become part of any modern CPU. then the benefit would be large, as any language could use i…

> i don't see the reduced development effort, after all, unless the language is only running on webassembly i still need to implement my own GC for other CPUs.

I'd think porting an existing GC to WASM is more effort than using WASM's GC for a GC'd language?

Post reply on HN