from Hacker News

Wasmtime 1.0: A Look at Performance

by mnemonik on 9/6/22, 5:03 PM with 22 comments

• by stevemk14ebr on 9/6/22, 11:54 PM

  It is very disappointing there are no embeddable, performant wasm runtimes. The language is perfect for embedded systems, it's a near asm level sandbox. But there's no good no_std or limited dependency runtimes! If wasm is to grow, it should work on this use case.

  I should be able to provide platform APIs to allocate memory, maybe do some floating point math, and then that's about it. Additional features would just be giving some additional API implementations the runtime needs to interact with the host machine.

  Context: this was a huge barrier for me on my project https://github.com/mandiant/STrace/blob/16859a811e4af7c68259...

• by jedisct1 on 9/6/22, 8:49 PM

  Probably a good time to run a new iteration of the Libsodium WebAssembly benchmarks.

• by jeroenhd on 9/6/22, 9:28 PM

  How do bytecode compilers like Cranelift compare to native images generated out of bytecode that's easier to optimize for pure machine code execution (Java, dotnet)?

  Perhaps more relevant: what's the point of taking machine code capable software, compiling it into WASM, and then compiling that back into machine code? A reinvention of FFI perhaps?

• by fwsgonzo on 9/7/22, 9:43 AM

  Happy to see they finally reduced the instantiation time to a few microseconds. I have had 1 micro in prod for another emulator, so I was wondering what the holdup was. Also see they are using madvise for CoW - it is fairly slow and I ended up not using it. That is, pagetable changes on Linux are just absolutely unusably slow on a larger scale, in production.