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

Wasm3 – A high performance WebAssembly interpreter in C

github.com

Post reply on HN
Print view View original

41–50 of 79 posts

Re: Wasm3 – A high performance WebAssembly interpreter in C

#41

Post by uasm »

ridiculous_fish wrote: post #14

This is pretty exciting if real: > Bytecode/opcodes are translated into more efficient "operations" during a compilation pass, generating pages of meta-machine code WASM compiled to a novel bytecode format aimed at efficient interpretation. > Commonly occurring sequences of operations can can also be optimized into a "fused" operation. Peephole optimizations producing fused opcodes, makes sense. > In M3/Wasm, the sta…

> "WASM translated to register-based bytecode. That's awesome!"

If the hardware executing this code is "stack-based" (or, does not offer enough general purpose registers to accomodate the funtion call) - this will need to be converted back to a stack-based function call (either at runtime, or beforehand). Wouldn't this intermediate WASM-to-register-based-bytecode translation be redundant then?

Re: Wasm3 – A high performance WebAssembly interpreter in C

#42

Post by saagarjha »

kbumsik wrote: post #30
CharlesW wrote: post #4

Why is an interpreter desirable when JIT compilers create significantly faster code? Is this primarily about embedded use?

iOS prohibits JIT for example.

More specifically, apps submitted to the App Store may not utilize JIT.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#43

Post by saagarjha »

sebcat wrote: post #27
newnewpdro wrote: post #9

Earlier quoted context omitted.

I suspect they're just saying they'd rather see a CPU implementing the wasm isa, in a facetious way.

AVR32 with JEM does this to some extent for Java. http://ww1.microchip.com/downloads/en/devicedoc/doc32000.pdf 3. Java Extension Module The AVR32 architecture can optionally support execution of Java bytecodes by including a JavaExtension Module (JEM). This support is included with minimal hardware overhead. EDIT: Not by implementing the ISA verbatim, but still neat though

ARM tried to do this with Jazelle, but the effort floundered: https://en.wikipedia.org/wiki/Jazelle

Re: Wasm3 – A high performance WebAssembly interpreter in C

#45

Post by tyingq »

uasm wrote: post #41
ridiculous_fish wrote: post #14

This is pretty exciting if real: > Bytecode/opcodes are translated into more efficient "operations" during a compilation pass, generating pages of meta-machine code WASM compiled to a novel bytecode format aimed at efficient interpretation. > Commonly occurring sequences of operations can can also be optimized into a "fused" operation. Peephole optimizations producing fused opcodes, makes sense. > In M3/Wasm, the sta…

> "WASM translated to register-based bytecode. That's awesome!" If the hardware executing this code is "stack-based" (or, does not offer enough general purpose registers to accomodate the funtion call) - this will need to be converted back to a stack-based function call (either at runtime, or beforehand). Wouldn't this intermediate WASM-to-register-based-bytecode translation be redundant then?

I don't know of any current physical stack machine CPUs.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#46

Post by saagarjha »

kevingadd wrote: post #31
ridiculous_fish wrote: post #14

This is pretty exciting if real: > Bytecode/opcodes are translated into more efficient "operations" during a compilation pass, generating pages of meta-machine code WASM compiled to a novel bytecode format aimed at efficient interpretation. > Commonly occurring sequences of operations can can also be optimized into a "fused" operation. Peephole optimizations producing fused opcodes, makes sense. > In M3/Wasm, the sta…

IR getting converted into an interpreter-oriented bytecode is pretty common. Mono does it for its interpreter and IIRC, Spidermonkey has historically done that as well. I'm not sure if V8 has ever interpreted from an IR (maybe now?) but you could view their original 'baseline JIT' model as converting into an interpreter-focused IR, where the IR just happened to be extremely unoptimized x86 assembly. Translating the s…

> The necessity of doing coloring to assign registers efficiently is kind of unfortunate

You don't have to do register allocation with coloring; it's just that most implementations do.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#47

Post by AlEinstein »

uasm wrote: post #41
ridiculous_fish wrote: post #14

This is pretty exciting if real: > Bytecode/opcodes are translated into more efficient "operations" during a compilation pass, generating pages of meta-machine code WASM compiled to a novel bytecode format aimed at efficient interpretation. > Commonly occurring sequences of operations can can also be optimized into a "fused" operation. Peephole optimizations producing fused opcodes, makes sense. > In M3/Wasm, the sta…

> "WASM translated to register-based bytecode. That's awesome!" If the hardware executing this code is "stack-based" (or, does not offer enough general purpose registers to accomodate the funtion call) - this will need to be converted back to a stack-based function call (either at runtime, or beforehand). Wouldn't this intermediate WASM-to-register-based-bytecode translation be redundant then?

What proportion of machines running web assembly are stack-based, would you say?

I would guess negligible.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#48

Post by saagarjha »

vnorilo wrote: post #33
ridiculous_fish wrote: post #14

This is pretty exciting if real: > Bytecode/opcodes are translated into more efficient "operations" during a compilation pass, generating pages of meta-machine code WASM compiled to a novel bytecode format aimed at efficient interpretation. > Commonly occurring sequences of operations can can also be optimized into a "fused" operation. Peephole optimizations producing fused opcodes, makes sense. > In M3/Wasm, the sta…

Sure this is neat stuff, but I don't think any of it is novel. Bochs is a good source for some bytecode vm performance wizardry [1], even if the bytecode in question is the x86 ISA. Regardless, kudos to the authors and nice to see a fast wasm interpreter done well. 1: http://www.emulators.com/docs/nx25_nostradamus.htm

Yeah, threaded interpretation is nothing new. Notably, Forth compilers have often used it; the iSH x86 emulator (https://github.com/tbodt/ish) is a more recent example of this technique.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#49

Post by saagarjha »

ridiculous_fish wrote: post #11
CharlesW wrote: post #4

Why is an interpreter desirable when JIT compilers create significantly faster code? Is this primarily about embedded use?

1. Some platforms do not have wasm JITs available, because nobody has written one. 2. Some platforms prohibit creating new executable pages, which prevents JITing. 3. Memory savings!

Plus some platforms allow all of the above, but need something that can run while the JIT warms up.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#50

Post by pjmlp »

w0utert wrote: post #29
CharlesW wrote: post #4

Why is an interpreter desirable when JIT compilers create significantly faster code? Is this primarily about embedded use?

Any JIT needs an interpreter to run code sections that are not compiled (yet), and large sections (I don't have any statistics, but I would guess a very sizable majority) of the code is 'cold' and will never get compiled at all. Compiling bytecode to machine code is a relatively expensive operation in itself so it only makes sense to do it for 'hot' sections (loops, functions that get called many times, etc).

There JIT implementations without interpreter phase, .NET being one of them.
Post reply on HN