5 ms·

This is why I'm optimistic about WebAssembly, beyond time and investment, what prohibits it from achieve performance parity with native?

stephc_int13 5y ago
Apple support?
ccgus 5y ago
There's no JIT for WebAssembly on iOS (at least last time I looked last year), so it's going to be much slower than it could otherwise be.
- ec109685 5y ago
  Are you sure about that? Why wouldn't WebAssembly in Safari support JIT?
pjmlp 5y ago
Politics. This is what Flash was already capable of doing in 2011 with CrossBridge, their C++ compiler stack. https://adobe-flash.github.io/crossbridge/ https://adobe-flash.github.io/crossbridge/ "Unreal Engine 3 Support for Adobe Flash Player - Unreal Tournament 3" https://www.youtube.com/watch?v=UQiUP2Hd60Y https://www.youtube.com/watch?v=UQiUP2Hd60Y Here we are 10 years later with WebAssembly still mostly stuck at MVP 1.0, browsers that bork WebGL experience thanks blacklisting, which no matter what will never go beyond OpenGL ES 3.0. Even if WebGPU gets released tomorrow, I would like to point out that WebGL 2.0 was released in 2017 and still isn't available across all browsers. Then there are all other native capabilities that I glanced over.
- mcphage 5y ago
  > This is what Flash was already capable of doing in 2011 with CrossBridge, their C++ compiler stack. Then why was the Android Flash experience so bad that it got quickly killed off? There was a time where Adobe could have shown a performant, stable version of mobile Flash, and Apple would have had to find a way to accept it. But it never got there, on any mobile OS.
  - pjmlp 5y ago
    Politics. While everyone was celebrating iOS victory over Flash, they were playing Flash games on iOS, AOT compiled to native code without knowing it. Adobe eventually let it go thanks to the competition of Cocos, Unreal and Unity.
handrous 5y ago
> This is why I'm optimistic about WebAssembly, beyond time and investment, what prohibits it from achieve performance parity with native? It's cross-platform VM-enabled bytecode? Approaching native performance very closely is the best plausible outcome. Measured on all metrics and not just pure number-crunching (start-up time generally, "cold" start-up, memory use, memory use over time, et c., all in real-world applications and not bespoke benchmarking programs) it's unlikely it'll even get very close. Close enough? Maybe, but I'm skeptical that there is such a (realistic) achievable state as "close enough" on a platform that runs on a small battery. Look at Android's decades of playing catch-up on performance & power use, for instance. [EDIT] Down-voters, please comment: do first-year CS principles and direct observation of existing, long-lived, real-world cross-platform VM systems (the JVM, for example) somehow not apply to WebAssembly?
criddell 5y ago
> what prohibits it from achieve performance parity with native? On what axes are you measuring performance? I care about how quickly and smoothly something runs, but also how much battery, memory, and bandwidth it consumes.

stephc_int13 5y ago

Apple support?

ccgus 5y ago

There's no JIT for WebAssembly on iOS (at least last time I looked last year), so it's going to be much slower than it could otherwise be.

ec109685 5y ago
Are you sure about that? Why wouldn't WebAssembly in Safari support JIT?

pjmlp 5y ago

Politics. This is what Flash was already capable of doing in 2011 with CrossBridge, their C++ compiler stack. https://adobe-flash.github.io/crossbridge/ https://adobe-flash.github.io/crossbridge/ "Unreal Engine 3 Support for Adobe Flash Player - Unreal Tournament 3" https://www.youtube.com/watch?v=UQiUP2Hd60Y https://www.youtube.com/watch?v=UQiUP2Hd60Y Here we are 10 years later with WebAssembly still mostly stuck at MVP 1.0, browsers that bork WebGL experience thanks blacklisting, which no matter what will never go beyond OpenGL ES 3.0. Even if WebGPU gets released tomorrow, I would like to point out that WebGL 2.0 was released in 2017 and still isn't available across all browsers. Then there are all other native capabilities that I glanced over.

mcphage 5y ago
> This is what Flash was already capable of doing in 2011 with CrossBridge, their C++ compiler stack. Then why was the Android Flash experience so bad that it got quickly killed off? There was a time where Adobe could have shown a performant, stable version of mobile Flash, and Apple would have had to find a way to accept it. But it never got there, on any mobile OS.
- pjmlp 5y ago
  Politics. While everyone was celebrating iOS victory over Flash, they were playing Flash games on iOS, AOT compiled to native code without knowing it. Adobe eventually let it go thanks to the competition of Cocos, Unreal and Unity.

handrous 5y ago

> This is why I'm optimistic about WebAssembly, beyond time and investment, what prohibits it from achieve performance parity with native? It's cross-platform VM-enabled bytecode? Approaching native performance very closely is the best plausible outcome. Measured on all metrics and not just pure number-crunching (start-up time generally, "cold" start-up, memory use, memory use over time, et c., all in real-world applications and not bespoke benchmarking programs) it's unlikely it'll even get very close. Close enough? Maybe, but I'm skeptical that there is such a (realistic) achievable state as "close enough" on a platform that runs on a small battery. Look at Android's decades of playing catch-up on performance & power use, for instance. [EDIT] Down-voters, please comment: do first-year CS principles and direct observation of existing, long-lived, real-world cross-platform VM systems (the JVM, for example) somehow not apply to WebAssembly?

criddell 5y ago

> what prohibits it from achieve performance parity with native? On what axes are you measuring performance? I care about how quickly and smoothly something runs, but also how much battery, memory, and bandwidth it consumes.