Show HN: I wrote a WebAssembly Interpreter and Toolkit in C
1–10 of 31 posts
Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C
#2I made Web49 because there are not many good tools for WebAssembly out there. WABT is close, but the interpreter is too slow and the tools megabytes in size each. Wasm3 is a bit faster but only contains an interpreter, nothing else.
Tooling for WebAssembly is held mostly by the browser vendors. It is such a nice format to work with when one removes all the fluff. WebAssembly tooling should not take seconds to do what should take milliseconds, and it should be able to be used as a library, not just a command line program.
I developed a unique way to write interpreters based on threaded code jumps and basic block versioning when I made MiniVM (https://github.com/FastVM/minivm). It was both larger and more dynamic than WebAssembly. Web49 started as a way to compile WebAssembly to MiniVM, but soon pivoted into its own Interpreter and tooling. I could not be happier with it in its current form and am excited to see what else It can do, with more work.
Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C
#3Any ideas on why miniwasm performs better on all the benchmarks except "trap," on which it performs decidedly worse?
Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C
#4Any ideas on why miniwasm performs better on all the benchmarks except "trap," on which it performs decidedly worse?
The benchmarks were run on MacOS, and actually execute an interrupt for debugging, MacOS then checks if the process is being debugged. Wasm3 just exit(1) and prints a message.
And as to why the rest are faster, I spent much time optimizing the interpreter and learning what the best way to write interpreters is. Its mostly jump threading and Mixed Data.
Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C
#5Any ideas on why miniwasm performs better on all the benchmarks except "trap," on which it performs decidedly worse?
Don't take this as anything other than speculation: I wonder if wasm3 is using musttail with opaque function calls in the instruction handlers. It will demolish performance, which is why I am only using computed gotos in mine (when available). Even switch-case is faster than musttail when you have to leave the tco-jumps. Which is (as an example) why one should not measure performance by fibonacci number generation. :)
Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C
#6How does it compare to Wasmtime? Do you have a list of supported wasm features?
Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C
#7Any ideas on why miniwasm performs better on all the benchmarks except "trap," on which it performs decidedly worse?
Don't take this as anything other than speculation: I wonder if wasm3 is using musttail with opaque function calls in the instruction handlers. It will demolish performance, which is why I am only using computed gotos in mine (when available). Even switch-case is faster than musttail when you have to leave the tco-jumps. Which is (as an example) why one should not measure performance by fibonacci number generation. :…
> I wonder if wasm3 is using musttail with opaque function calls in the instruction handlers. It will demolish performance, which is why I am only using computed gotos in mine (when available). Even switch-case is faster than musttail when you have to leave the tco-jumps.
This doesn't match with my experience. After working on this problem a lot, I came to the conclusion that musttail with opaque function calls is one of the best ways of getting good code out of the compiler: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...
Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C
#8I made Web49 because there are not many good tools for WebAssembly out there. WABT is close, but the interpreter is too slow and the tools megabytes in size each. Wasm3 is a bit faster but only contains an interpreter, nothing else. Tooling for WebAssembly is held mostly by the browser vendors. It is such a nice format to work with when one removes all the fluff. WebAssembly tooling should not take seconds to do what…
> I developed a unique way to write interpreters based on threaded code jumps and basic block versioning when I made MiniVM (https://github.com/FastVM/minivm). It was both larger and more dynamic than WebAssembly.
I'd be very interested to read more about this. It looks like you are using "one big function" with computed goto (https://github.com/FastVM/Web49/blob/main/src/interp/interp....). My experience working on this problem led me to the same conclusion as Mike Pall, which is that compilers do not do well with this pattern (particularly when it comes to register allocation): http://lua-users.org/lists/lua-l/2011-02/msg00742.html
I'm curious how you worked around the problem of poor register allocation in the compiler. I've come to the conclusion that tail calls are the best solution to this problem: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...
Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C
#9I am afraid it doesn't work on linux.
Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C
#10Earlier quoted context omitted.
Don't take this as anything other than speculation: I wonder if wasm3 is using musttail with opaque function calls in the instruction handlers. It will demolish performance, which is why I am only using computed gotos in mine (when available). Even switch-case is faster than musttail when you have to leave the tco-jumps. Which is (as an example) why one should not measure performance by fibonacci number generation. :…
> I wonder if wasm3 is using musttail with opaque function calls in the instruction handlers. It will demolish performance, which is why I am only using computed gotos in mine (when available). Even switch-case is faster than musttail when you have to leave the tco-jumps. This doesn't match with my experience. After working on this problem a lot, I came to the conclusion that musttail with opaque function calls is on…
I meant having an opaque function inside your instruction handler. My assembly looks like crap if something doesn't get inlined. Because I have no way of achieving this I simply cannot use TCO. It runs fibonacci faster, but anything that uses memory is way worse because it pushes and pops a ton of registers on the instruction handler itself, and not the slow-path opaque function.
An instruction handler here being a dispatch function. It handles a single instruction.
Reading your post it says so under Limitations. Opaque calls trashes performance. I guess we agree, but then again I was just reading my assembly, so I had no reason to doubt myself.