-
Notifications
You must be signed in to change notification settings - Fork 24
Explore Wasmtime as an alternative WebAssembly runtime #458
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
There was recent developments on bytecodealliance/wasmtime#7311. I tried to use Pulley on Nordic on the |
Thank you for starting a conversation about this in the BA's Zulip, @ia0! <3 As @alexcrichton said over there, we'll gladly help out with making Wasmtime a viable option however we can. Alex already filed two issues[1, 2], which should address the issues with Pulley bytecode size, and having to have the bytecode in RAM. Besides that, Alex also mentioned being able to reduce the size of the runtime itself, by removing the dependency on Serde. We know that there are other ways to shrink the binary size, but perhaps the biggest one might come from disabling a feature: SIMD support incurs a substantial size increase, because of how many opcodes need to be handled. Disabling that should shrink the interpreter meaningfully. |
Thank you and Alex for the quick answers and follow-up! Let me describe how WebAssembly is used in Wasefire and answer Alex's questions:
I always use
Applets use less than the WebAssembly MVP. The current interpreter doesn't even support SIMD. It also has optional floats (disabled by default). If you want to check some actual wasm modules, you can run I'm currently on vacations (with the kid thus little time), but as soon as I'm back I'll try to see if I can add Wasmtime support behind a cargo feature. The main difficulty will be the fact that the scheduler currently assumes the runtime to return control flow on host function calls. I guess I'll be able to use the async API of Wasmtime for this purpose (without async runtime, just calling poll myself). Another will be the fact that the current interpreter accepts a way to always link imported functions, but that's only to support linking new applets on old platforms as long as the imported function is allowed to return an error (there's a common format for all functions) at runtime. That's probably not going to be a blocker. I'll post updates on this issue. Footnotes
|
A bit delayed, but thank you for writing that up! It'll take some time to fully digest this but I hope to poke at this in the future. In the meantime bytecodealliance/wasmtime#10285 triggered another thought/recommendation, you'll want to be sure to set Also, to confirm but I suspect you're already doing this, if you strip the binary before compiling it (e.g. remove the |
Sorry for the very long delay. I finally got time to use the new version in #819. You can see the diff for the tuning I had to do (rather simple). In terms of performance it's essentially 20x faster than what I currently use, uses 2x the memory, and 2.5x the flash. So it seems usable, I'll try to integrate it in the final product. You can also see that compared to Wasmi, it has comparable performance, uses 50% more memory (but that's probably just my tuning, I could probably just ask for 32k wasm stack instead of 64k), but uses 2x less flash. Also important, the changes on the cwasm were significative, the module is now 15k. |
Oh that's awesome, thanks for the update! FWIW the |
For Pulley this is the case (and I guess it makes sense). I reduced it to 16k and seen the memory reduction. Regarding memory usage, there are only 3 allocations of more than 1kB:
This seems very reasonable to me. The only remaining limitation is the binary size, but I'll just optimize wasmtime for size (since that's the biggest part, 70kB to 80kB) and pulley-interpreter for perf (since it gives 40% perf improvement for double the footprint from 25k to 50k). |
That's something the custom page sizes proposal can help with, which is already supported by Wasmtime. It sounds like that should work well for your use case, potentially with page sizes of 4kb, or even less. |
Oh right yes I forgot about that stack, sorry! That should definitely be ok to decrease as you see fit. I'm not sure I reproduced exactly right but locally I was seeing a 680k binary for the wasm-bench folder compiled to a thumb target, and with bytecodealliance/wasmtime#10727 I was able to get that number down to 580k, so if you don't need simd that should help? That should also shrink the size of the VM allocation too by removing the (probably unused) vector registers from the VM state, leaving just float/integer ops. |
Good point. That's definitely going to be useful when we'll support multi-applets. For now this is not a blocker.
Weird, the repo should be somewhat hermetic. Running the following command at commit d85f65661519e5159d3d79d240e12ae1dc70b60:
should give:
Indeed I don't need SIMD. The current interpreter I'm using don't even support them (and floats are behind a feature flag). I'll follow the PR. |
Aha I was having some various issues which I have now resolved. I couldn't find |
Uh oh!
There was an error while loading. Please reload this page.
Now that Wasmtime has no-std support, it becomes a possible alternative for the platform WASM runtime. This task should track the feasibility of using Wasmtime, since many roadblocks are expected (page size, memory and binary footprint, supported target architectures, releasing control flow, etc).
In particular, we should try to use Pulley.
Action items:
opensk
example (disabled by Trade interpreter footprint for performance pre-computing a side table #804)The text was updated successfully, but these errors were encountered: