wasmtime

Thanks for that link! There goes my Saturday morning. After a bunch of middle clicking I landed here [0]. So if I understand correctly, the current stack switching proposal depended on exception handling to be implemented first for resume.throw, so that bit was blocked until now. But it's also further along than you might assume [1], i.e. you can already invoke Wasmtime with `-W stack-switching` and hit the boundaries where the experimental implementation breaks. Sadly though, like many ambitious Wasm things that don't have revenue directly attached to them, it now seems partly a case of finding someone willing to sponsor or finish the remaining work [2]. I also found the list of open stack-switching issues[3] useful. (also, minor nit - Wasm != Wasmtime) [0]: https://github.com/bytecodealliance/wasmtime/issues/10248 [1]: https://github.co

Hello HN, For my own needs I needed a powerful WASM engine that provides JIT acceleration, and use it from the convenience of the Swift Package Manager. So I ended up wrapping wasmtime (a Rust project) https://github.com/bytecodealliance/wasmtime/ The SPM package does support most platforms swift supports, including mobile where JIT is simply not available. I'd be happy to hear from you if this is something you may be interested in using and what are your WASM use cases. Thanks :+1:

It's possible to run WebAssembly programs from the command line (without any GUI) using WASI (see e.g. https://github.com/WebAssembly/WASI). Thus if the user downloads pdfconverter.wasi , and the user already has e.g. wasmtime installed, they can run `wasmtime pdfconverter.wasi input.pdf output.pdf` from the command line (see https://github.com/bytecodealliance/wasmtime/blob/main/docs/... for details). In addition to the web site, the Electron app and the Chrome extension, you may want to distribute a command-line version of your tools as WASI-style .wasm program files. If you do so, I would exclusively use the them this way, from the command line.

A few months ago someone wrote a much faster -O0 backend for LLVM, though it seems it didn't get much attention upstream: https://discourse.llvm.org/t/tpde-llvm-10-20x-faster-llvm-o0... Discussion: https://news.ycombinator.com/item?id=45072481 There are also codegen projects that don't use LLVM IR that are faster like Cranelift: https://github.com/bytecodealliance/wasmtime/tree/main/crane...

Cranelift does not use copy-and-patch. Consider, for example, this file, which implements part of the instruction generation logic for x64: https://github.com/bytecodealliance/wasmtime/blob/main/crane... Copy-and-patch is a technique for reducing the amount of effort it takes to write a JIT by leaning on an existing AOT compiler's code generator. Instead of generating machine code yourself, you can get LLVM (or another compiler) to generate a small snippet of code for each operation in your internal IR. Then codegen is simply a matter of copying the precompiled snippet and patching up the references. The more resources are poured into a JIT, the less it is likely to use copy-and-patch. You get more control/flexibility doing codegen yourself. But see also Deegen for a pretty cool example of trying to push this approach as far as possible:

Smalltalk predates Lisp machines and didn't originally compile to native code at all. I don't remember if Limbo did. Oberon isn't image-based (you can't save and restore the memory state of the running system) and didn't originally define a machine-independent bytecode format, and the one it had for many years has been removed from the current version. Wasm usually isn't image-based either; though it has a clear pathway for doing so, for example Wasmtime still doesn't implement that functionality: https://github.com/bytecodealliance/wasmtime/issues/3017

Sure, but your add-ons will need access to some of the world, which right now requires giving them access to all of WASI, as far as I know. There’s no permissions model. That’s worse than the JVM. (It seems like they want to implement one… someday. It’s vague: https://github.com/bytecodealliance/wasmtime/blob/main/docs/...)

That is amazing news! Thank you. https://github.com/bytecodealliance/wasmtime/blob/main/pulle...

Wasmtime's epoch system was designed specifically to have a much, much lower performance impact than fuel metering, at the cost of being nondeterministic. Since different embeddings have different needs there, wasmtime provides both mechanisms. Turning epochs on should be trivial if your system provides any sort of concurrency: https://github.com/bytecodealliance/wasmtime/blob/main/examp...

I had no idea what fuel is until this discussion. What's the rationale? Just preventing infinite loops from hanging the host? If the inefficiency is the counter, what if you just calculated an instruction offset - start < threshold every once in a while? This probably makes no sense, ignore it, I'm way in over my head. [1] https://github.com/bytecodealliance/wasmtime/issues/4109 [2] https://github.com/bytecodealliance/wasmtime/blob/main/examp...

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 :)

Wasmtimes C bindings for components are still a work in progress. In general C programming is always going to require more work than Rust programming, due to the limitations of C abstractions, but at the moment it’s also held back by how much energy has gone into the C bindings, which is much less than the Rust bindings which many of the maintainers, myself included, created and are using in production at their day jobs. More info: https://github.com/bytecodealliance/wasmtime/issues/8036 Several folks have volunteered work on the C bindings over the last year or two, with this contributor making progress most recently: https://github.com/bytecodealliance/wasmtime/pulls?q=is%3Apr...

What is the state of WASI vs. emscripten? I have tried wasmtime (which downloaded more than 400 crates to build) with wasi-libc, only to hit this issue: https://github.com/bytecodealliance/wasmtime/issues/8068 With emscripten, which can package the required files instead of accessing the file system. everything just worked. But emscripten is occasionally described as "unmaintained".

Yes: Go: https://go.dev/blog/wasi Rust: https://github.com/bytecodealliance/wasmtime/blob/main/docs/...

9x larger in LoC, 50x larger in comments. I had a wall of supporting tokei but decided against it, but the short of it is, LLVM is phenomenally massive, and libfirm at 135kloc and 35kloc of comments is but a raindrop that is in the 15Mloc+ that is LLVM. Perhaps instead of looking towards libfirm, we should look at cranelift. It is of comparable size and actually includes 12kloc of documentation, not just comments. https://github.com/bytecodealliance/wasmtime/tree/main/crane...