4 ms·

>despite not yet reaching bare-metal levels of performance and energy efficiency. "Not yet"? It will never reach "bare-metal levels of performance and energy e

by coldtea 10mo ago

>despite not yet reaching bare-metal levels of performance and energy efficiency. "Not yet"? It will never reach "bare-metal levels of performance and energy efficiency".

creata 10mo ago
Why? My only guess is that the instructions don't match x86 instructions well (way too few Wasm instructions) and the runtime doesn't have enough time to compile them to x86 instructions as well as, say, GCC could.
- HPsquared 10mo ago
  To be fair, x86 instructions don't match internal x86 processor architecture either.
  - 201984 10mo ago
    How don't they? Most x86 instructions map to just one or two uops as you can see at https://uops.info https://uops.info
flohofwoe 10mo ago
FWIW the native and WASM versions of my home computer emulators are within about 5% of each other (on an ARM Mac), e.g. more or less 'measuring noise': https://floooh.github.io/tiny8bit/ https://floooh.github.io/tiny8bit/ You can squeeze out a bit more by building with -march=native, but then there's no reason that a WASM engine couldn't do the same.
- jasonjmcghee 10mo ago
  SIMD and multithreading support really helped with closing the performance gap. Still surprised about the 5% though- I’ve generally seen quite a bit more of a gap.
  - flohofwoe 10mo ago
    Maybe the emulator code is particularly WASM friendly ... it's mostly bit twiddling on 64-bit integers with very little regular integer math (except incrementing counters) and relatively few memory load/stores.
kannanvijayan 10mo ago
I'd have to take a contrary view on that. It'll take some time for the technologies to be developed, but ultimately managed JIT compilation has the potential to exceed native compiled speeds. It'll be a fun journey getting there though. The initial order-of-magnitude jump in perf that JITs provided took us from the 5-2x overhead for managed runtimes down to some (1 + delta)x. That was driven by runtime type inference combined with a type-aware JIT compiler. I expect that there's another significant, but smaller perf jump that we haven't really plumbed out - mostly to be gained from dynamic _value_ inference that's sensitive to _transient_ meta-stability in values flowing through the program. Basically you can gather actual values flowing through code at runtime, look for patterns, and then inline / type-specialize those by deriving runtime types that are _tighter_ than the annotated types. I think there's a reasonable amount of juice left in combining those techniques with partial specialization and JIT compilation, and that should get us over the hump from "slightly slower than native" to "slightly faster than native". I get it's an outlier viewpoint though. Whenever I hear "managed jitcode will never be as fast as native", I interpret that as a friendly bet :)
- rudedogg 10mo ago
  > JIT compilation has the potential to exceed native compiled speeds The battlecry of Java developers riding their tortoises. Don’t we have decades of real-world experience showing native code almost always performs better? For most things it doesn’t matter, but it always rubs me the wrong way when people mention this about JIT since it almost never works that way in the real world (you can look at web framework benchmarks as an easy example)
  - pjmlp 10mo ago
    Only if it doesn't make use of dynamic linking, reflection and is written to take advantage of value types. AOT compilers without PGO data usually tend to perform worse when those conditions aren't met. Which is why the best of both worlds is using JIT caches that survive execution runs.
  - anotherhue 10mo ago
    Yeah I've heard this my whole career, and while it sounds great it's been long enough that we'd be able to list some major examples by now. What are the real world chances that a) one's compiled code benefits strongly from runtime data flow analysis AND b) no one did that analysis at the compilation stage? Some sort of crazy off label use is the only situation I think qualifies and that's not enough.

by coldtea 10mo ago

>despite not yet reaching bare-metal levels of performance and energy efficiency. "Not yet"? It will never reach "bare-metal levels of performance and energy efficiency".

creata 10mo ago

Why? My only guess is that the instructions don't match x86 instructions well (way too few Wasm instructions) and the runtime doesn't have enough time to compile them to x86 instructions as well as, say, GCC could.

HPsquared 10mo ago
To be fair, x86 instructions don't match internal x86 processor architecture either.
- 201984 10mo ago
  How don't they? Most x86 instructions map to just one or two uops as you can see at https://uops.info https://uops.info

flohofwoe 10mo ago

FWIW the native and WASM versions of my home computer emulators are within about 5% of each other (on an ARM Mac), e.g. more or less 'measuring noise': https://floooh.github.io/tiny8bit/ https://floooh.github.io/tiny8bit/ You can squeeze out a bit more by building with -march=native, but then there's no reason that a WASM engine couldn't do the same.

jasonjmcghee 10mo ago
SIMD and multithreading support really helped with closing the performance gap. Still surprised about the 5% though- I’ve generally seen quite a bit more of a gap.
- flohofwoe 10mo ago
  Maybe the emulator code is particularly WASM friendly ... it's mostly bit twiddling on 64-bit integers with very little regular integer math (except incrementing counters) and relatively few memory load/stores.

kannanvijayan 10mo ago

I'd have to take a contrary view on that. It'll take some time for the technologies to be developed, but ultimately managed JIT compilation has the potential to exceed native compiled speeds. It'll be a fun journey getting there though. The initial order-of-magnitude jump in perf that JITs provided took us from the 5-2x overhead for managed runtimes down to some (1 + delta)x. That was driven by runtime type inference combined with a type-aware JIT compiler. I expect that there's another significant, but smaller perf jump that we haven't really plumbed out - mostly to be gained from dynamic _value_ inference that's sensitive to _transient_ meta-stability in values flowing through the program. Basically you can gather actual values flowing through code at runtime, look for patterns, and then inline / type-specialize those by deriving runtime types that are _tighter_ than the annotated types. I think there's a reasonable amount of juice left in combining those techniques with partial specialization and JIT compilation, and that should get us over the hump from "slightly slower than native" to "slightly faster than native". I get it's an outlier viewpoint though. Whenever I hear "managed jitcode will never be as fast as native", I interpret that as a friendly bet :)

rudedogg 10mo ago
> JIT compilation has the potential to exceed native compiled speeds The battlecry of Java developers riding their tortoises. Don’t we have decades of real-world experience showing native code almost always performs better? For most things it doesn’t matter, but it always rubs me the wrong way when people mention this about JIT since it almost never works that way in the real world (you can look at web framework benchmarks as an easy example)
- pjmlp 10mo ago
  Only if it doesn't make use of dynamic linking, reflection and is written to take advantage of value types. AOT compilers without PGO data usually tend to perform worse when those conditions aren't met. Which is why the best of both worlds is using JIT caches that survive execution runs.
- anotherhue 10mo ago
  Yeah I've heard this my whole career, and while it sounds great it's been long enough that we'd be able to list some major examples by now. What are the real world chances that a) one's compiled code benefits strongly from runtime data flow analysis AND b) no one did that analysis at the compilation stage? Some sort of crazy off label use is the only situation I think qualifies and that's not enough.