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

231–240 of 520 posts

Re: WASM 3.0 Completed

#231

Post by teleforce »

j0e1 wrote: post #4

> Garbage collection. In addition to expanding the capabilities of raw linear memories, Wasm also adds support for a new (and separate) form of storage that is automatically managed by the Wasm runtime via a garbage collector. Staying true to the spirit of Wasm as a low-level language, Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of stru…

It's very refreshing and good to see WASM is embracing GC in addition to non-GC support. This approach is similar to D language where both non-GC and GC are supported with fast compilation and execution.

By the way now you can generate WASM via Dlang compiler LDC [1].

[1] Generating WebAssembly with LDC:

https://wiki.dlang.org/Generating_WebAssembly_with_LDC

Re: WASM 3.0 Completed

#232

Post by cesarb »

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…

>

Plus ça change...

Re: WASM 3.0 Completed

#233

Post by lyu07282 »

flohofwoe wrote: post #74
hinkley wrote: post #58

Earlier quoted context omitted.

I was even trying to be charitable and read the feature list for elements that would thin down a third party DOM access layer, but other than the string changes I’m just not seeing it. That’s not enough forward progress. WASM is just an extremely expensive toy for browsers until it supports DOM access.

It's a chicken egg situation. The people already using WASM either don't care about the DOM or had realized long ago that going through a JS shim works just as well, the rest just complain time and time again that WASM has no DOM access whenever there's a HN thread about WASM, but usually don't even use WASM for anything.

Especially if there was major momentum of people writing their web applications with wasm, there would be a reason to eventually get that massive undertaking of creating the ABI for that working. Then all those applications could just recompile to make use of this new hypothetically faster API. The bigger issue here is that it just doesn't make any sense to write frontend code in rust or go or whatever in the first place.

The whole js ecosystem evolved to become a damn good environment to write UIs with, people don't know the massive complexity this environment evolved to solve over decades.

Re: WASM 3.0 Completed

#234

Post by zarzavat »

renehsz wrote: post #97
jjcm wrote: post #12

I'm definitely excited to see 64 bit as a default part of the spec. A lot of web apps have been heavily restricted by this, in particular any online video editors. We see a bunch of restrictions due to the 32 bit cap today here at Figma. One thing I'm curious though is whether mobile devices will keep their addressable per-tab memory cap the same. It's often OS defined rather than tied to the 32 bit space.

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?

Re: WASM 3.0 Completed

#235

Post by marcosdumay »

baq wrote: post #125
jsheard wrote: post #104

Earlier quoted context omitted.

The comedy option would be to use the new multi-memory feature to juggle a bunch of 32bit memories instead of a 64bit one, at the cost of your sanity.

didn't we call it 'segmented memory' back in DOS days...?

And turned out we have the transistors to avoid it, but it's a really good optimization for CPUs nowadays.

At least most people design non-overlaping segments. And I'm not sure wasm would gain anything from it, being a virtual machine instead of real.

Re: WASM 3.0 Completed

#236

Post by azakai »

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?

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

Re: WASM 3.0 Completed

#237

Post by 0x457 »

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?

Probably only after Components and WIT are stabilized. No point of making it wihtout it IMO.

Re: WASM 3.0 Completed

#238

Post by jesse__ »

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?

Hot take alert

> When is WASM finally going to be able to touch the DOM?

Coming from a web background, and having transitioned to games / realtime 3D applications...

Fuck the DOM dude. The idea that programming your UI via not one but TWO DSLs, and a scripting language, is utter madness. In principal, it might sound good (something something separation of concerns, or whatever-the-fuck), but in reality you always end up with this tightly coupled garbage fire split across a pile of different files and languages. This is not the way.

We need to build better native UI libraries that just open up a WebGL context and draw shit to that. DearIMGUI can probably already do like 85% of what modern webapps do.

Anyways .. /rant

Re: WASM 3.0 Completed

#239

Post by azakai »

baxuz wrote: post #213
j0e1 wrote: post #4

> Garbage collection. In addition to expanding the capabilities of raw linear memories, Wasm also adds support for a new (and separate) form of storage that is automatically managed by the Wasm runtime via a garbage collector. Staying true to the spirit of Wasm as a low-level language, Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of stru…

Does this allow for shrinking the WebAssembly.Memory object? - https://github.com/WebAssembly/design/issues/1397 - https://github.com/WebAssembly/memory-control/issues/6 This is a crucial issue, as the released memory is still allocated by the browser.

Wasm GC is entirely separate from Wasm Memory objects, so no, this does not help linear memory applications.

Re: WASM 3.0 Completed

#240

Post by kannanvijayan »

baxuz wrote: post #213
j0e1 wrote: post #4

> Garbage collection. In addition to expanding the capabilities of raw linear memories, Wasm also adds support for a new (and separate) form of storage that is automatically managed by the Wasm runtime via a garbage collector. Staying true to the spirit of Wasm as a low-level language, Wasm GC is low-level as well: a compiler targeting Wasm can declare the memory layout of its runtime data structures in terms of stru…

Does this allow for shrinking the WebAssembly.Memory object? - https://github.com/WebAssembly/design/issues/1397 - https://github.com/WebAssembly/memory-control/issues/6 This is a crucial issue, as the released memory is still allocated by the browser.

No, I don't think it will. Pointers to managed objects are opaque, and aren't actually backed by the wasm memory buffer. The managed heap is offloaded.

Shrinking the memory object shouldn't require any special support from GC, just an appropriate API hook. It would, as always, be up to the application code running inside the module to ensure that if a shrink is done, that the program doesn't refer to memory addresses past the new endpoint.

If this hasn't been implemented yet, it's not because it's been waiting on GC, but more that it's not been prioritized.

Post reply on HN