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

71–79 of 79 posts

Re: Wasm3 – A high performance WebAssembly interpreter in C

#71

Post by MaxBarraclough »

saagarjha wrote: post #43
sebcat wrote: post #27

Earlier quoted context omitted.

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

It doesn't make much sense to build hardware to run an intermediate language. Java bytecode isn't optimised; almost all optimisation is meant to happen in the JIT. If you build a processor that runs bytecode directly, when does the optimisation occur? Presumably never.

Low-horsepower platforms are probably the best place to give it a go, as they may struggle to run a respectable JIT compiler, but as you say, Jazelle didn't catch on.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#73

Post by vshymanskyy »

MuffinFlavored wrote: post #72

> Node v13.0.1 (interpreter) 28 59.5x https://github.com/wasm3/wasm3/blob/master/test/benchmark/co... 59.5x faster than node.js at what? Executing WebAssembly?

V8 has a built-in (pure, no JIT etc.) interpreter of WASM. Which is quite slow according to this test.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#74

Post by tom_mellior »

jashmatthews wrote: post #65
tom_mellior wrote: post #40

Earlier quoted context omitted.

But that's an allocator to virtual registers that don't try to correspond to (a valid number of) physical CPU registers. Sure it's easy to allocate to a large number of registers. It's harder to do it to a small number, like the project discussed here seems to claim to do.

I could be completely wrong but it looks like what this does is more like stack-caching. One operand, if it's the result of the last instruction, should already be in "virtual r0" which is already in a register. For the other operand of the opcode, it's an infinite set of "registers" at an offset from the stack pointer: https://github.com/wasm3/wasm3/tree/b1462d450ca367e39e4b2eb4...

You're right. This doesn't use a register machine in the usual sense of the word. It's kind of the software analog to accumulator machines.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#75

Post by colejohnson66 »

tyingq wrote: post #61
uasm wrote: post #60

Earlier quoted context omitted.

Stacks are used extensively across the x86 family [0] [0] - https://en.wikipedia.org/wiki/X86_calling_conventions

"Has a stack" isn't the same as "Has a stack based ISA".

To expand: a Forth machine or similar would be a stack based ISA. Using a stack is a different matters; Pretty much every ISA uses stacks.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#76

Post by kbumsik »

vips7L wrote: post #69
saagarjha wrote: post #42

Earlier quoted context omitted.

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

Is there any specific reason for this?

Executing instructions dynamically from memory (JIT does this) exposes potential security issues. A good example is the famous Specter vulnerability.

Specter itself is not JIT-specific but it is known to very hard to reproduce that the only current viable target environment is JIT. So JavaScript was affected by Specter.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#77

Post by naasking »

MaxBarraclough wrote: post #71
saagarjha wrote: post #43

Earlier quoted context omitted.

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

It doesn't make much sense to build hardware to run an intermediate language. Java bytecode isn't optimised; almost all optimisation is meant to happen in the JIT. If you build a processor that runs bytecode directly, when does the optimisation occur? Presumably never. Low-horsepower platforms are probably the best place to give it a go, as they may struggle to run a respectable JIT compiler, but as you say, Jazelle…

The hardware would perform the optimisation using typical means. Instruction lookahead can be used for caching the stack slots to be used in registers, for instance.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#78

Post by MaxBarraclough »

naasking wrote: post #77
MaxBarraclough wrote: post #71

Earlier quoted context omitted.

It doesn't make much sense to build hardware to run an intermediate language. Java bytecode isn't optimised; almost all optimisation is meant to happen in the JIT. If you build a processor that runs bytecode directly, when does the optimisation occur? Presumably never. Low-horsepower platforms are probably the best place to give it a go, as they may struggle to run a respectable JIT compiler, but as you say, Jazelle…

The hardware would perform the optimisation using typical means. Instruction lookahead can be used for caching the stack slots to be used in registers, for instance.

> The hardware would perform the optimisation using typical means.

The HotSpot JIT is an impressive feat of compiler engineering. The advanced optimisations it performs cannot practically be performed in hardware.

Modern CPUs are capable of, for instance, loop-detection, but they haven't put optimising compilers out of a job, and never will.

Jazelle would add no value on a modern ARM server, for instance. You'd get far better performance out of HotSpot, or some other modern JVM.

Re: Wasm3 – A high performance WebAssembly interpreter in C

#79

Post by sound_and_form »

thermals wrote: post #34
setheron wrote: post #2

The neater article seems to be about M3 interpreter https://github.com/soundandform/m3#m3-massey-meta-machine Tbh, I couldn't get the eureka moment though. Might try to read in the AM ;)

Yeah, this is a good way to design a fast interpreter! It's traditionally called a "threaded interpreter", or (somewhat confusingly) "threaded code": https://en.wikipedia.org/wiki/Threaded_code http://www.complang.tuwien.ac.at/forth/threaded-code.html You can see an example of this particular implementation style (where each operation is a tail call to a C function, passing the registers as arguments) at the second l…

Thanks for the links! I've long searched google trying to find a similar "tail-cail" interpreter. No wonder I couldn't hit anything -- it was so poorly named! :)
Post reply on HN