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

WASI 0.3

bytecodealliance.org

Post reply on HN
Print view View original

81–90 of 103 posts

Re: WASI 0.3

#81

Post by jason_oster »

Dwedit wrote: post #49
kettlecorn wrote: post #29

Earlier quoted context omitted.

That's not accurate. I Googled for a recent performance benchmark and found this which indicates Wasm offers a notable performance gain: https://medium.com/@hashbyt/webassembly-vs-javascript-perfor...

My task in question was a number crunching task, basically doing multiply-and-add for 336-bit integers. I wrote a JS version, and a C version compiled into WASM by using Zig. You'd think that WebAssembly would trounce JS here, but it actually didn't. The JS code had been written carefully to avoid allocations, and also avoiding the built-in JavaScript BigInt. I rolled my own BigInt instead using an array of numbers.…

> and had to run glue code to copy things in and out of Webassembly memory.

Not surprising. The FFI boundary is always a bottleneck. If you can eliminate it, you will see where the WASM JIT shines. You have far more control over mechanical sympathy with C/WASM than JavaScript (though far from perfect).

Also, consider publishing your findings and ask for reviews for optimization opportunities.

Re: WASI 0.3

#82

Post by [deleted] »

tete wrote: post #40
hectaman wrote: post #26

Earlier quoted context omitted.

I don't think it's fair to say this work has happened in the shadows. I work on CNCF wasmCloud, and I know how hard we try to make this content available. - Many standing meetings organized around SIGs, all on the public community calendar: https://calendar.google.com/calendar/u/0/newembed?src=events... - A dedicated Zulip: https://bytecodealliance.zulipchat.com/ - Conferences organized around exactly these topics: W…

> - "What is a Component (and Why)?" (WasmCon 2023): https://www.youtube.com/watch?v=tAACYA1Mwv4 At 18:00 the speaker states something like "It should not be Systems Interface but Standard Interfaces" which honestly sounds like a different project. As an implementer or even as just a user in general, can it be trusted that tomorrow it isn't something completely different? Seems like an odd standard to follow. (EDIT a…

[deleted]

Re: WASI 0.3

#83

Post by hmry »

phickey wrote: post #80
hmry wrote: post #78

Does the stackfull async implementation use the stack-switching proposal? I was under the impression that it's not implemented in most runtimes (very difficult to retrofit into existing implementations), and only available on x86_64 Linux in wasmtime.

No, the stack switching proposal is not used. Stack switching is a set of core Wasm opcodes that permit a guest to change its own stack. Instead of using opcodes inside the Wasm, the stackful async mode of the component model’s ABI calls out into the component model implementation where it can manipulate the stacks with special host powers - JSPI is sufficient on web engines to express this, and wasmtime manages gues…

Thank you, that's great to hear. I was worried it would be a long time before most runtimes could use WASIp3 if it required stack-switching.

Re: WASI 0.3

#84

Post by yoshuaw »

phickey wrote: post #50
lenkite wrote: post #46

Earlier quoted context omitted.

Why was the component model not expressed in LISP syntax like the way WAT is ? Why have yet another custom IDL language with bespoke parsing rules ?

There is a wat (s expression) syntax for the component model. The problem with the wat syntax for both Wasm and the component model is they’re a reflection of a binary format, and therefore are terrible for writing by hand. They’re designed to be written by tools, and the text format is just to help you understand the binary format. I’ve written Wasm and component model wat extensively over the last decade to develop…

Seconding this. Writing .wast files by hand is kind of fun as a novelty, but it's in no way something I'd want to maintain interfaces in.

Declarative interfaces via the WIT format are so much more readable in comparison; I'm really happy that's the direction we took for the component model.

Re: WASI 0.3

#85

Post by syrusakbary »

tete wrote: post #40
hectaman wrote: post #26

Earlier quoted context omitted.

I don't think it's fair to say this work has happened in the shadows. I work on CNCF wasmCloud, and I know how hard we try to make this content available. - Many standing meetings organized around SIGs, all on the public community calendar: https://calendar.google.com/calendar/u/0/newembed?src=events... - A dedicated Zulip: https://bytecodealliance.zulipchat.com/ - Conferences organized around exactly these topics: W…

> - "What is a Component (and Why)?" (WasmCon 2023): https://www.youtube.com/watch?v=tAACYA1Mwv4 At 18:00 the speaker states something like "It should not be Systems Interface but Standard Interfaces" which honestly sounds like a different project. As an implementer or even as just a user in general, can it be trusted that tomorrow it isn't something completely different? Seems like an odd standard to follow. (EDIT a…

If you are looking for a Systems Interface, I don't think the Component Model will be a good fit

Re: WASI 0.3

#86

Post by lifthrasiir »

azakai wrote: post #75
garganzol wrote: post #18

Wrong direction. WASI should be simple and stable. Initially, it was revolving around a simple Unix-like API model and it was close to perfect. Now, there is an opinionated component model which is an unneeded overcomplication that should have never been considered as part of WebAssembly spec IMHO. A real component model is a separate development and cannot be blindly tied to a particular ecosystem. Otherwise, its ma…

> Let's keep WebAssembly lean and fast! Note that wasm is still lean and fast - WASI is not part of core wasm, but layered on top. That is, it is possible to implement wasm without WASI. That is also true for other wasm proposals like WasmGC. It is very possible that parts of the ecosystem will not implement certain proposals if they don't make sense there (e.g. parts of the embedded ecosystem may never add GC, etc.)…

I have seriously attempted to write my own WebAssembly 3.0 implementation recently, and while I did finish the whole thing [1] that left me a bitter taste about WasmGC which turned out to be very annoying to implement. In fact, I originally wanted to avoid GC but spectest assumed that GC is always available and I had no other option but implementing one in order to make use of spectest in the first place.

[1] https://github.com/lifthrasiir/wah/

Re: WASI 0.3

#87

Post by himata4113 »

derefr wrote: post #68
b33j0r wrote: post #11

Love/hate with this one. How was I supposed to follow this? I tried, and few things were publicly visible for nearly two years. I last checked in march and it looked like no progress had been made. That makes me very suspicious of wasiv3. Funny enough, I already implemented a bunch of the promises (pun not intended) and think that freestanding wasm with custom integrations is the more likely future. The promise of wa…

> The promise of wasi components has not been fulfilled. The market wants to hotload and link artifacts dynamically. The wasi project requires insider wizardry to use it that way: the offering has been statically linking components before you ship. Defeating 99% of the use cases. I think both of these points on the spectrum (on the one end, fully static linking of WASI components within a monolithic single-source pro…

I do specifically that and abandoned WASI in favor of freestanding with shared memory regions + PIC memory region. It works today and is easily extensible as well as increadibly fast, sandboxing is not as strong since modules can read code they don't own and modify data they do not own, but splitting modules into "trusted" and "untrusted" largely mitigated those issues as memory has write bit stripped for execution during untrusted modules, only allowing data they own to be modified. Sensitive data lives outside the runtime and has to be fetched with (slower) host methods.

Point being, if you rely on a non standard specification of developer defined wasi api subspec you might as well just go with freestanding.

Re: WASI 0.3

#89

Post by apitman »

lifty wrote: post #12

If you have used WASI in the past, can you mention your use case? Very curious if you found it to give you an edge compared to other sandboxing like containers or VMs.

Technically WASI 0.1, but I used it (via Extism[0]) to implement a simple library[1] that's written in Rust, but lets you easily add login to backends in Rust, Go, and Node. Would be trivial to add other lanugages supported by Extism.

Overall I loved the dev experience. It's sort of like writing a C library that can be dynamically linked in other languages, but with much better security and much easier distribution because you don't need to worry about the OS or CPU architecture. Literally the same .wasm file everywhere.

[0]: https://extism.org/

[1]: https://github.com/lastlogin-net/DecentAuth

Re: WASI 0.3

#90

Post by panick21_ »

lifthrasiir wrote: post #86
azakai wrote: post #75

Earlier quoted context omitted.

> Let's keep WebAssembly lean and fast! Note that wasm is still lean and fast - WASI is not part of core wasm, but layered on top. That is, it is possible to implement wasm without WASI. That is also true for other wasm proposals like WasmGC. It is very possible that parts of the ecosystem will not implement certain proposals if they don't make sense there (e.g. parts of the embedded ecosystem may never add GC, etc.)…

I have seriously attempted to write my own WebAssembly 3.0 implementation recently, and while I did finish the whole thing [1] that left me a bitter taste about WasmGC which turned out to be very annoying to implement. In fact, I originally wanted to avoid GC but spectest assumed that GC is always available and I had no other option but implementing one in order to make use of spectest in the first place. [1] https:/…

Interfacing with GC is usually hard, how should have it been done?
Post reply on HN