Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I wrote a WebAssembly Interpreter and Toolkit in C

github.com

Post reply on HN
Print view View original

11–20 of 31 posts

Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C

#11

Post by haberman »

fwsgonzo wrote: post #10
haberman wrote: post #7

Earlier quoted context omitted.

> 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 d…

Yes our solution was to make all fallback functions into tail calls. It solves the problem, but requires a lot of discipline and can be a bit awkward.

I recently saw this, which is a very interesting approach for using non-tail-call fallback functions without trashing the code: https://chromium-review.googlesource.com/c/v8/v8/+/4116584

Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C

#13

Post by fwsgonzo »

haberman wrote: post #11
fwsgonzo wrote: post #10

Earlier quoted context omitted.

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 d…

Yes our solution was to make all fallback functions into tail calls. It solves the problem, but requires a lot of discipline and can be a bit awkward. I recently saw this, which is a very interesting approach for using non-tail-call fallback functions without trashing the code: https://chromium-review.googlesource.com/c/v8/v8/+/4116584

That's very interesting! Thanks!

Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C

#14

Post by [deleted] »

4984 wrote: post #2

I 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…

[deleted]

Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C

#16

Post by naasking »

haberman wrote: post #8
4984 wrote: post #2

I 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…

> 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

Note that that message is from twelve years ago. A lot's changed since then, not just in compilers but in CPUs. Branch prediction is a lot better now.

Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C

#17

Post by haberman »

naasking wrote: post #16
haberman wrote: post #8

Earlier quoted context omitted.

> 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…

> 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 Note that that message is from twelve years ago. A lot's changed since then, not just in compilers but in CPUs. Branch prediction is a lot better now.

Mike's primary complaint is bad register allocation. It is very important to keep the most important state consistently in registers. In my experience, compilers still struggle to do good register allocation in big and branchy functions.

Even perfect branch prediction cannot solve the problem of unnecessary spills.

Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C

#19

Post by 10000truths »

haberman wrote: post #17
naasking wrote: post #16

Earlier quoted context omitted.

> 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 Note that that message is from twelve years ago. A lot's changed since then, not just in compilers but in CPUs. Branch prediction is a lot better now.

Mike's primary complaint is bad register allocation. It is very important to keep the most important state consistently in registers. In my experience, compilers still struggle to do good register allocation in big and branchy functions. Even perfect branch prediction cannot solve the problem of unnecessary spills.

Does providing a hint to the compiler using the register keyword address the issue sufficiently?

Re: Show HN: I wrote a WebAssembly Interpreter and Toolkit in C

#20

Post by thechao »

heleninboodler wrote: post #18
habibur wrote: post #9

I am afraid it doesn't work on linux.

Worked flawlessly for me on linux. The readme should mention 'emcc' and 'wasm3' as prerequisites for following the bench.py instructions, though.

I'm on macOS, and if I do this:

    > git clone ...
    > make -j
    > ./bin/wasm2wat ./test/core/address.wast
I get:

    >>> ./bin/wat2wasm test/core/address.wast 
    unexpected word: `` byte=256
Post reply on HN