8 ms·

The article seems to evaluate Wasm as it were a framework upon which apps are built. It's not that, it's an orthogonal technology allowing CPU optimisations and

by xipix 8mo ago

The article seems to evaluate Wasm as it were a framework upon which apps are built. It's not that, it's an orthogonal technology allowing CPU optimisations and reuse of native code in the browser. Against that expectation, it has been a huge success despite not yet reaching bare-metal levels of performance and energy efficiency. One such example: audio time stretch in the browser based upon a C++ library [1]. There is no way that if this were implemented in JS that it could deliver (a) similar performance or (b) source code portability to native apps. [1] https://bungee.parabolaresearch.com/change-audio-speed-pitch https://bungee.parabolaresearch.com/change-audio-speed-pitch

coldtea 8mo 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 8mo 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 8mo ago
    To be fair, x86 instructions don't match internal x86 processor architecture either.
    - 201984 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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.
pjmlp 8mo ago
Yes there is, WebGPU compute shaders, or misusing WebGL fragment shaders.

by xipix 8mo ago

coldtea 8mo 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 8mo 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 8mo ago
  To be fair, x86 instructions don't match internal x86 processor architecture either.
  - 201984 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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.

pjmlp 8mo ago

Yes there is, WebGPU compute shaders, or misusing WebGL fragment shaders.