Stream: wamr

Topic: WAMR Open TSC meeting - 2023-08-29 9:00 AM(UTC)

Wang Xin (Aug 28 2023 at 02:31):

Hi all, we are going to have a WAMR open TSC meeting. This time we will be focused on the topic of moving WASI to component model:
https://github.com/WebAssembly/WASI/pull/549.

Anyone who is interested in this topic is welcome to join the meeting.

Meeting Bridge info: https://github.com/bytecodealliance/wasm-micro-runtime/wiki/TSC-meeting-notes#wamr-tsc-meeting-2023-08-29-900-am-utc

Sorry for that the meeting time is bad for US timezone, we will make video record. Please be free to forward the invitation.

Ayako Akasaka (Aug 29 2023 at 10:44):

Thank you for the excellent presentation.

Let me bring several questions here. Sorry if I was missing your explanation

1. I really want to have dynamic linking for tiny devices. Presentation said Shared memory will be achieved by WasmGC or mem.ref, but will it be possible to provide natural I/F for the Wasm module developer? And is it possible to share only a part of memory?
2. I fail to understand which part of the component model spec consumes a footprint. Multi-memory feature?
3. I want to agree with the co-existence of the preview1 module and preview2 component. I guess WasmCG is also promoting this way. Is there any blocker to this idea?
4. Who is going to share the performance measurement data? without data, no one can judge, right?

Luke Wagner (Aug 29 2023 at 17:57):

I may not be the best person to answer, but just to provide a few partial answers:

1. I'm not aware of how to use WasmGC to achieve better performance or less runtime footpring vs. the Component Model for dynamic linking or passing data between modules using linear memory languages (e.g., for C, C++, Go, Rust, ...): you'll need to copy from linear memory to GC memory or vice versa or both, and this can end up doing more total copies than the Component Model (in addition to generating garbage). Additionally, if runtime footprint is a concern, WasmGC will have significantly more impact than the Component Model. Separately, on the topic of mem.ref: because most linear-memory languages don't have a good language-native way to refer to multiple memories at the same time, I think mem.ref will end up having a similar amount of copying as the Component Model in practice (but without the benefit of a static component signature to enable tooling and virtualization).
2. A single component containing a single core module should have essentially the same runtime behavior/footprint as just the core module (if the preview1-to-2 adapter is used, that will add overhead, but our goal is to have wasi-libc target preview2 directly, avoiding the need for this adapter). Two linked components (each containing a core module) can be fused into a single core module embedding both original core modules (therefore, with multiple memories) plus a small amount of additional synthesized wasm thunks that sit in-between the two original core modules and perform the copying between memories. It's not clear if this should be considered "overhead", though, since the component model still enables you to link multiple .o's, .a's or .wasm's that want to share memory into a single component with a single memory (using wasm-ld, the same as with core wasm today). Thus, these multi-component scenarios represent new use cases, not regressions on existing use cases.
3. Yes, I think co-existence is possible and expected, in two ways: (1) engines can support both preview1 modules and preview2 components at the same time (Wasmtime is), (2) new preview2 interfaces specified in Wit can be translated to equivalent Witx interfaces by applying the Canonical ABI to the Wit, allowing single core modules to execute using new Preview2 interfaces.

Wang Xin (Aug 30 2023 at 06:28):

meeting notes and shared materials: https://github.com/bytecodealliance/meetings/blob/main/wamr/2023/wamr-08-29.md

Ralph (Aug 30 2023 at 08:15):

good stuff. I believe my MegaCorp can use wamr in some key situations with wasi/components, so I am really looking forward to this, and to contributing code to wamr as well.

Wang Xin (Aug 30 2023 at 14:14):

@Ayako Akasaka, @Luke Wagner I would like to share the understanding on performance impacts from my recently study and I may be wrong. We should distinguish two major situations here:

1. Using single memory for static linking or shared everything dynamic linking. It doesn't require data copy between two memories, so it is the fastest approach, however the problem is it is mostly limited to C/C++/Rust today.
2. Using two memories: this enables isolation and multi-langauges interoperation, and doing data copy between two memories seems a neccessary cost. In WAMR's dynamical linking implementation, we basically copy stack args between two instances for a inter-module call. The cost for implementing the exact method defined in component model proposal may largely depend on the runtime design technique. For example I am curious whether the wasmtime can quickly copy the list/string data without bearing the burden of refering meta data type for every call.

About using WasmGC for two memories case, if I remember it correctly, WasmGC operation is between the wasm stack and gc object, linear memory is not involved. Assuming the GC objects are located a global heap managed by the runtime and handles can be shared by multiple instances, the execution path for passing data will be short. On another hand, component will require malloc and free in the linear memory some times, like when flatten argments is more than the max number (15) or types list/string is used in the function type. If the function body is short execution, then malloc/free could be a big overhead. In such situation, WasmGC is expected to be more efficient.

Wang Xin (Aug 30 2023 at 14:29):

Single memory based linking is probably not what component model intends to address and actually it is more relavent to the compiler toolchain. But single memory based linking is always important usage in my view, in some situations either per-module isolation or multi-languages is not that critical but performance can be critical in the most time. I am hoping it can be also covered in the CM proposal. A big reason is after WASI is turned to CM, people will start to develop and ship components since their work eventually has dependency on WASI. Given everything is component, it will be great and also important that we can reuse shared components from registry service for doing static linking of Wasm.

Luke Wagner (Aug 30 2023 at 14:50):

Those are great points @Wang Xin. I agree with your description of the two major cases and that both are important to support well in the toolchain when producing components that use WASI. I also think that, while more work may be required to flesh out and polish, we can support both very well, including reuse of shared-everything libraries distributed as core modules in a registry. I also think that good support of both will be important not just for WAMR and embedded use cases, but for plenty of other use cases across the wasm ecosystem as well, ultimately giving developers more choices for how to build their applications.

That is an interesting use case for WasmGC that I hadn't considered, thanks for explaining. My expectation is that the >15-flattened-parameter case will be relatively rare, and that the majority of Wit functions will flatten to a small number of parameters that point into linear memory for any variable-sized (list or string) parameters. Moreover, even in these many-parameter cases, due to strong spatial and temporal locality, I expect the cost of copying parameters between linear memories would be low and amortized by the cost of the overall call. That being said, if we were to find the use of WasmGC to be a measurable win, the design of lifting and lowering in the Component Model allow us to add WasmGC as an additional canonical ABI option (canonopt in the grammar) in an interoperable, backwards-compatible manner in the future.

The cost for implementing the exact method defined in component model proposal may largely depend on the runtime design technique. For example I am curious whether the wasmtime can quickly copy the list/string data without bearing the burden of refering meta data type for every call.

You're right, it does depend on the implementation technique. In the current implementation, Wasmtime's AOT "fusion" of lifting+lowering adapters avoids any use of type metadata at runtime, by construction: fusion essentially produces a single loop for every list in the function type that reads from the source linear memory, performs any data-type coercion or validation, and writes directly into the destination linear memory, all guided by the type and the canonopts of the lifting and lowering side, which are also statically known at AOT compilation time.

Christof Petig (Aug 30 2023 at 19:09):

I have some doubts about the two allocations per call constant overhead of poll_oneoff, especially when used frequently for async signaling. I wish it would be able to receive a borrow<list> :wink: and return a bit flag in the common <64 descriptor case.

Luke Wagner (Aug 30 2023 at 22:44):

@Christof Petig I agree; I've also suggested changing that particular interface, and we still can in the Preview 2 timeframe. Dan is already talking about changing wasi-poll in this issue, so maybe comment there with what you'd like to see.

Christof Petig (Sep 01 2023 at 15:25):

Christof Petig said:

I have some doubts about the two allocations per call constant overhead of poll_oneoff, especially when used frequently for async signaling. I wish it would be able to receive a borrow<list> :wink: and return a bit flag in the common <64 descriptor case.

Oh, I realize I confused im- and export ABIs, for imported functions a list argument is borrowed by default. So the allocation happens only for the result, overriding a one time result for cabi_realloc like in the adapter would be possible but still adds overhead.

Ayako Akasaka (Oct 22 2023 at 13:51):

@Wang Xin
Thank you for your answer. then let me clarify this part.

Single memory based linking is probably not what component model intends to address and actually it is more relavent to the compiler toolchain. But single memory based linking is always important usage in my view, in some situations either per-module isolation or multi-languages is not that critical but performance can be critical in the most time. I am hoping it can be also covered in the CM proposal.

wasi-libc shared library support is what you are saying as "Single memory based linking". isn't it?
Isn't this within the scope of the Component Model's module-linking specification?
From the previous answer, componentize-py is using the same method, I thought this was the method implicitly, just because it wasn't explicitly stated.

Ayako Akasaka (Oct 22 2023 at 16:08):

sorry. my question is not clear. Let me revise it later.

Last updated: Oct 23 2024 at 20:03 UTC