undefined | Better HN

0 pointsphickey1y ago0 comments

Wasmtime maintainer here - curious to hear what went wrong, I and several other users of wasmtime have production embeddings under no_std, so it should do everything you need, including building out WASI preview 2 support. You can find me on the bytecode alliance zulip if you need help.

0 comments

11 comments · 2 top-level

lasiotus1y ago· 8 in thread

I'm not the OP, but I have a similar experience with Motor OS: wasmi compiles and works "out of the box", while wasmtime has a bunch of dependencies (e.g. target-lexicon) that won't compile on custom targets even if all features are turned off in wasmtime.

phickeyOP1y ago

Not sure how to help with this much information but I've built and run wasmtime on some pretty squalid architectures (xtensa and riscv32 microcontrollers among others) but the right collection of features might not be obvious. We can help you find the right configuration on the Bytecode Alliance zulip or the wasmtime issue tracker if you need it.

lasiotus1y ago

> Not sure how to help with this [...]

I guess not much can be done at the moment: dependencies are often the primary obstacle in porting crates to new targets, and just comparing the list of dependencies of wasmtime vs wasmi gives a pretty good indication of which crate is a bit more careful in this regard:

https://crates.io/crates/wasmtime/33.0.0/dependencies https://crates.io/crates/wasmi/0.47.0/dependencies

phickeyOP1y ago

Wasmtime has many capabilities that wasmi does not, and therefore has more optional dependencies, but the required set of dependencies has been portable to every platform I've targeted so far. If anything does present a concrete issue we are eager to address it. For example, you could file an issue on target-lexicon describing how to reproduce your issue.

1 more reply

sitkack1y ago

Is that wasmtime in interpreter mode? I didn't see a rv32 backend to wasmtime (in cranelift) or did I not look in the right place.

What are the min memory requirements for wasmtime/cranelift?

phickeyOP1y ago

There’s now an interpreter in wasmtime called Pulley. It’s an optimizing interpreter based on Cranelift, which generates interpreter opcodes which are more efficient to traverse than directly interpreting the Wasm binary.

I have run wasmtime on the esp32 microcontrollers with plenty of ram to spare, but I don’t have a measurement handy.

1 more reply

9d1y ago

But if this benchmark is right, then wasmtime is 5x faster than wasmi for it:

https://github.com/khvzak/script-bench-rs

herobird1y ago

Wasmtime, being an optimizing JIT, usually is ~10 times faster than Wasmi during execution.

However, execution is just one metric that might be of importance.

For example, Wasmi's lazy startup time is much better (~100-1000x) since it does not have to produce machine code. This can result in cases where Wasmi is done executing while Wasmtime is still generating machine code.

Old post with some measurements: https://wasmi-labs.github.io/blog/posts/wasmi-v0.32/

Always benchmark and choose the best tool for your usage pattern.

9d1y ago

That's a good point I didn't think about.

I guess it's like v8 compared to quickjs.

Anyway all this talk about wasm makes me want to write a scriptable Rust app!

Gazoche1y ago· 1 in thread

I think I was a bit spooked by the examples (https://github.com/bytecodealliance/wasmtime/tree/main/examp...), and the need to implement platform dependencies in C code (which would have complicated the build process). Makes sense since it's a more complex and mature project, but Wasmi on the other hand was just a pure Rust dependency that only required a single line in the Cargo.toml. So in short I went the lazy route :)

phickeyOP1y ago

All of the C primitives there implemented in (unsafe) Rust, but we built that example for an audience that already had some platform elements in C. We'll try to improve the example so that both integrating with C, and using pure Rust, are covered.

j / k navigate · click thread line to collapse

0 comments