Show HN: M3 – A high performance WebAssembly interpreter in C • Hacker News Board

Show HN: M3 – A high performance WebAssembly interpreter in C

#1

Post by sound_and_form » Wed, Jul 17, 2019, 5:00 AM UTC

Show HN: M3 – A high performance WebAssembly interpreter in C
github.com

Re: Show HN: M3 – A high performance WebAssembly interpreter in C

#2

Post by burfog » Wed, Jul 17, 2019, 9:19 AM UTC

This features a shocking dependence on the C compiler doing tail-call optimization. This, I've never seen before. The code probably blows through the stack if it isn't optimized.

Re: Show HN: M3 – A high performance WebAssembly interpreter in C

#3

Post by sound_and_form » Thu, Jul 18, 2019, 3:10 AM UTC

burfog wrote: post #2

This features a shocking dependence on the C compiler doing tail-call optimization. This, I've never seen before. The code probably blows through the stack if it isn't optimized.

I would have prefered the adjective "clever" over "shocking" :) But you're absolutely correct: it does rely entirely on tail-call optimizations. I hadn't seen this as an actual real world concern. Its stack usage is sufficiently minimal for debugging and development of the project itself. And production code would only ever be optimized. Maybe there are risks I can't foresee, but I'm gonna keep at it 'cause the upside is a blazingly fast interpreter.

Re: Show HN: M3 – A high performance WebAssembly interpreter in C

#4

Post by burfog » Thu, Jul 18, 2019, 6:30 AM UTC

sound_and_form wrote: post #3

burfog wrote: post #2

This features a shocking dependence on the C compiler doing tail-call optimization. This, I've never seen before. The code probably blows through the stack if it isn't optimized.

I would have prefered the adjective "clever" over "shocking" :) But you're absolutely correct: it does rely entirely on tail-call optimizations. I hadn't seen this as an actual real world concern. Its stack usage is sufficiently minimal for debugging and development of the project itself. And production code would only ever be optimized. Maybe there are risks I can't foresee, but I'm gonna keep at it 'cause the upsid…

The traditional loop around a switch has some advantages. That "break" or "continue" is an unconditional branch, so it is a small piece of code and is always correctly predicted. It's almost free. By doing this, you get to avoid repeating code for every instruction. The common code that happens for every instruction thus appears only once in your CPUs cache, instead of being numerous copies.