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

131–140 of 520 posts

Re: WASM 3.0 Completed

#131

Post by davexunit »

flohofwoe wrote: post #112
dcchambers wrote: post #103

Earlier quoted context omitted.

While technically possible - the calls to javascript slow things down and you're never going to get the performance of just writing javascript in the first place, much less the performance of skipping javascript altogether.

The calls to JS are quite cheap, when trusting the diagrams in here it's about 10 clock cycles on a 2 GHz CPU per call (e.g. 200 million calls per second): https://hacks.mozilla.org/2018/10/calls-between-javascript-a... The only thing that might be expensive is translating string data from the language-specific string representation on the WASM heap into the JS string objects expected by the DOM API. But this same pr…

Wasm could have had a concept of a string. I frequently mourn the rejection of the imo excellent stringref proposal. https://github.com/WebAssembly/stringref

Re: WASM 3.0 Completed

#132

Post by flohofwoe »

gspr wrote: post #100
flohofwoe wrote: post #63

Earlier quoted context omitted.

That old thing again ;) Direct DOM access doesn't make any sense as a WASM feature. It would be at best a web-browser feature which browser vendors need to implement outside of WASM (by defining a standardized C-API which maps to the DOM JS API and exposing that C API directly to WASM via the function import table - but that idea is exactly as horrible in practice as it sounds in theory). If you need to manipulate th…

> If you need to manipulate the DOM - just do that in JS, calling from WASM into JS is cheap, and JS is surprisingly fast too. From the point of view of someone who doesn't do web development at all, and to whom JS seems entirely cryptic: This argument is weird. Why is this specific (seemingly extremely useful!) "web thing" guarded by a specific language? Why would something with the generality and wide scope of WASM…

Think of it as traditional FFI (foreign function interface) situation.

Many important libraries have been written in C and only come with a C API. To use those libraries in non-C languages (such as Java) you need a mechanism to call from Java into C APIs, and most non-C language have that feature (e.g. for Java this was called JNI but has now been replaced by this: https://docs.oracle.com/en/java/javase/21/core/foreign-funct...), e.g. C APIs are a sort of lingua franca of the computing world.

The DOM is the same thing as those C libraries, an important library that's only available with an API for a single language, but this language is Javascript instead of C.

To use such a JS library API from a non-JS language you need an FFI mechanism quite similar to the C FFI that's been implemented in most native programming languages. Being able to call efficiently back and forth between WASM and JS is this FFI feature, but you need some minimal JS glue code for marshalling complex arguments between the WASM and JS side (but you also need to do that in native scenarios, for instance you can't directly pass a Java string into a C API).

Re: WASM 3.0 Completed

#133

Post by MisterTea »

boricj wrote: post #73
MisterTea wrote: post #57

Earlier quoted context omitted.

> in order to have a more secure alternative to the ASM programs What security implications are there in graphical calculators in terms of assembler language?

Exam mode, or test mode. It's something that appeared about ten years ago, to ensure that a graphical calculator isn't loaded with cheats or has certain features enabled. The technical reason is that the RESET button no longer clears all of the calculator's memory (think Flash, not RAM) and proctors like to see a flashing LED that tells them everything's fine. It's a flawed idea and has led to an arms race, where man…

Sad state of affairs. I had no idea this was a thing.

Re: WASM 3.0 Completed

#134

Post by mattlondon »

But looks like you still cannot open a raw TCP or UDP socket? Who needs this internet network thing huh?

I appreciate it is a potential security hole, but at least make it behind a flag or something so it can be turned on.

Re: WASM 3.0 Completed

#135

Post by alabhyajindal »

sestep wrote: post #129
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…

For what it's worth, I also tried Binaryen from TypeScript and similarly found it frustrating. I switched to using wasm-tools from Rust instead, and have found that to be a vastly better experience.

Isn't wasm-tools for working with Wasm modules? Maybe I'm missing something. I was using Binaryen to compile an AST to WebAssembly text. Also worth mentioning that Binaryen is the official compiler/toolchain for this purpose which is why I expected more from it.

Re: WASM 3.0 Completed

#136

Post by titzer »

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…

What were your specific pain points? One thing that can be annoying is validation errors. That's one of the reasons that Wizard has a --trace-validation flag that prints a nicely-formatted depiction of the validation algorithm as it works.

Re: WASM 3.0 Completed

#137

Post by zb3 »

Jtsummers wrote: post #90
quix0t3 wrote: post #71

steve job's ghost will prevent wasm adoption.

> steve job's ghost will prevent wasm adoption. https://webassembly.org/features/ That isn't updated for Safari 26, but by that table Safari 18 is only missing 3 standardized features that Chrome supports, with a fourth that is disabled by default. So what's the point of your comment? Just to make noise and express your ignorance?

What ignorance? Safari doesn't support the most important additions:

- memory64

- multiple memories

- JSPI (!!)

I recently explored the possibility of optimizing qemu-wasm in browser[0].. and it turns out that the most important features were those Safari doesn't implement.

[0] https://zb3.me/qemu-wasm-test/

Re: WASM 3.0 Completed

#138

Post by titzer »

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…

Wizard supports all of Wasm 3.0, but as a research tool, it only has an interpreter and baseline compiler tier (no opt compiler), so it doesn't run as fast as, say, V8 or wasmtime.

Re: WASM 3.0 Completed

#139

Post by flohofwoe »

cjs_ac wrote: post #120
nostrademons wrote: post #114

Earlier quoted context omitted.

Like C, which offloads IO to the standard library?

It's still there - you can still do I/O in C, even if you have to call a library function. In WebAssembly, there's no mechanism for I/O of any sort.

...in WASM you also call a function to do IO though? That function is just provided by the host environment via the function import table, but conceptually it's the exact same thing as a Linux syscall, a BIOS int-call or calling into a Windows system DLL.

Re: WASM 3.0 Completed

#140

Post by titzer »

aag wrote: post #9

Does anyone know whether the exception handling implementation supports restartable exceptions like Common Lisp's and Scheme's?

No, that functionality would fall under the stack-switching proposal, which builds on the tags of Wasm exception handling.
Post reply on HN