search

asynchronics / asynchronix

High-performance asynchronous computation framework for system simulation
Apache License 2.0
170 stars 9 forks source link

WASI support #1

Closed leon-thomm closed 3 months ago

leon-thomm commented 1 year ago

Are there any plans to provide wasm32-wasi target support, presumably with single threaded simulation fallback? This would increase portability (for a developer) and security (for a client) for non-performance critical testing purposes.

Currently, the espresso machine example compiles successfully with

cargo build --package asynchronix --target wasm32-wasi --example espresso_machine

but running the generated espresso_machine.wasm on a WASM VM will fail where the executor tries to spawn threads unchecked. As far as I know, all use of std APIs not supported by WASI (such as threading) will need to be made target-dependent with macros.

I am not sure how much asynchronix depends on multi-threading and unsafe code, and hence how hard it would be to introduce fallbacks for WASI.

sbarral commented 1 year ago

I admit I have no experience with wasm targets, but my guess is that supporting wasm with the current multi-threaded executor architecture would be difficult. As you noted, even in single-threaded mode, 1 worker thread is always spawned from the main executor thread and changing this behavior would be a major change.

There is, however, a plan to provide a dedicated single-threaded simulator with !Sync channels and tasks. The primary motivation for this is to eliminate atomic synchronization overhead for light workloads that do not benefit from parallel execution, but it would certainly make sense to ensure it supports wasm32-wasi out of the box. I can't give any horizon for this though, it is only a medium-level priority at the moment.

I am very curious about your use-case: are you at the liberty to share why you wish to run Asynchronix on a wasm target?

In any case, I will leave this issue open to ensure it is not forgotten when work on a single-threaded simulator begins.

leon-thomm commented 1 year ago

There is, however, a plan to provide a dedicated single-threaded simulator with !Sync channels and tasks. [...] it would certainly make sense to ensure it supports wasm32-wasi out of the box.

That sounds great.

I am very curious about your use-case: are you at the liberty to share why you wish to run Asynchronix on a wasm target?

For portability. I recently wrote a tiny cache coherence simulator with several parameters (block size, replacement policy, etc.), and it turned out useful that I could simply compile it to wasm32-wasi and send the .wasm file to my peers, who can run small benchmarks with their own configurations in an arbitrary environment (with quite reasonable performance, actually). But I understand that this might not be top of the agenda.

sbarral commented 4 months ago

Just a small update: this will be resolved in v0.3 (already works in our private branch).

sbarral commented 3 months ago

Done, courtesy of #24! :tada:

In fact it is now even possible to use the simulator API from the JS side via protobuf messages, but this is for now a somewhat experimental feature. There is sadly no JS library to abstract the protobuf layer at the moment, so one must perform (de)serialization in JS based on the simulation.proto schema, for instance with protobuf.js.

This won't make its way to crates.io before v0.3 is officially published though.