15 ms·

Analyzing the Performance of WebAssembly vs. Native Code

250 points by furcyd 8y ago

snek 8y ago
Seems like the tl;dr is that v8 and spidermonkey need to work on adding more optimization tiers to their wasm piplines
- roca 8y ago
  Another tl;dr is that if you care about WebAssembly performance, use Firefox.
  - yodon 8y ago
    > if you care about WebAssembly performance, use Firefox Unless you have customers or want them, because Firefox's market share is generally too small to base your entire business around.
    - realPubkey 8y ago
      I think it was meant that YOU, as a single human being, should use firefox
    - est31 8y ago
      In the old days there were websites using flash or silverlight and they had a screen "in order to use this you must use flash" and for some reason, people did download and install flash so that they could watch the cat videos or whatever.
      - pjmlp 8y ago
        The big difference is that without them they would see a broken square, with Chrome or Safari they would still see it, just a bit slower.
- maeln 8y ago
  Most performance spec for WASM are not even finished (SIMD, Thread, ...). Doing a benchmark will be interesting when at least SIMD as been properly finished and implemented.
  - deleted 8y ago
    [deleted]
- Veedrac 8y ago
  You don't need ‘more’ tiers per se, because WASM can be fully compiled from the outset. Two tiers should be fine.
pier25 8y ago
I never expected WebAssembly to be as fast as native only to be significantly faster than JavaScript. Considering the popularity of Electron, if WebAssembly does get as fast as native or at least 80% there (and that's a really big if) it would easily become the cross platform language for the vast majority of desktop applications. For mobile we will always be dragged down by Apple and its reticence to embrace web technologies. It's 2019 and we can't even show a add to home screen native banner.
- forrestthewoods 8y ago
  > can't even show a add to home screen native banner. That sounds like a feature.
  - untog 8y ago
    Not really. Progressive Web Apps are a much better model for users than the App Store because they get to use the app immediately then decide later whether they want to keep it on their home screen or not. We've all become very used to the App Store but honestly the experience is pretty crappy.
    - jacobolus 8y ago
      Web apps are inherently mediocre on every platform. There’s enough advantage from being accessible via URL, usable on any device, live updating, etc. to compensate that for many uses. But using web apps daily for any serious work is a huge loss in resource use, usability, polish, ... The one that makes me saddest though is that web apps seem to be getting worse over time. For example most of Google’s suite of web apps were dramatically better a decade ago.
      - onion2k 8y ago
        The problem of mediocre apps is not what they're written in. Millions of people happily use apps built on web technologies every day without even realising. Similarly, millions of people use badly made native apps and hate every second. The tech is not the problem.
theninjagreg 8y ago
The paper is comparing to native. How does it WASM compare to Javascript?
- markdog12 8y ago
  > We find that while WebAssembly runs faster than JavaScript (on average 1.3× faster across SPEC CPU)
xiphias2 8y ago
Compilation speed should be part of the benchmarks, as it's critical for WebASM. The best would be to use the Clang optimization setting with the most similar compilation speed to compare runtime speeds. As an example the article mentions suboptimal register allocation, but without compile time comparision there's no way to know if there really is a simple way to improve WebGL implementation.
- comex 8y ago
  It's true that Clang can't compete with the JITs in question on speed. Even at the settings with the most comparable quality of generated code, Clang will be much slower, because its internal design is primarily geared towards maximum optimization potential at high optimization levels, with lower optimization levels as more of an afterthought. But that's beside the point. The paper isn't suggesting switching to Clang or to the algorithms Clang is using. Rather, it's treating Clang's output as an approximation of 'optimal' code generation for the given C code. There are various reasons to compare it to WebAssembly JITs: - For one, the paper identifies specific reasons the JIT output is slower, which shows potential areas of improvement they could focus on. - The comparison also provides a sort of upper bound on how much the JITs theoretically could be improved. It's only a weak upper bound; the upper bound of code quality achievable at the required performance levels is lower and would be more relevant, but there's no way to measure that. - It also indicates the potential of adding a higher tier to the JIT that optimizes very hot code using slower algorithms. - And finally, most entertainingly, the benchmarks help answer age-old questions like "can WebAssembly replace native code?" :) Or, at least, "for what applications can WebAssembly replace native code and have acceptable performance?"...
- gpderetta 8y ago
  The problem is that the compilation budget is much smaller when it impacts the perceived startup time of the application. For a performance critical application it is much easier to throw resources to offline compilation than for online compilation. Do typical web assembly implementations cache the result of compilation?
hackcasual 8y ago
They disable vectorization on native, so hard to call this a true apples-to-apples comparison
- Veedrac 8y ago
  It makes sense since WASM's SIMD isn't ready yet, and a paper saying “WASM is slower because SIMD isn't ready yet” would be rather uninformative to browser vendors.
  - hackcasual 8y ago
    I think the problem when you're doing X vs. native is you're implicitly saying "X vs. the best possible situation." I think it's fine to compare it against vector-less operations, but they should also benchmark against more vanilla native compiler settings.
    - vanderZwan 8y ago
      > when you're doing X vs. native is you're implicitly saying "X vs. the best possible situation." Not really, any sensible benchmark would be "X vs. the most relevant point of comparison".
quangio 8y ago
The benchmark seems to use only browsers' built in VMs to run WebAssembly (more like the the efficiency of different VM JIT compilers compared to native). How about running them in standalone webassembly VM like WAVM (it does more aggressive optimization, use LLVM for JIT), Asmble (running in JVM), or Wasmer (use Cranelift like Firefox does, maybe a little bit faster than Firefox) (I just skimmed the paper, sorry if i miss something)
- est31 8y ago
  > use Cranelift like Firefox does To my knowledge, Cranelift in Firefox is still disabled by default. https://searchfox.org/mozilla-central/source/modules/libpref/init/all.js#1483 https://searchfox.org/mozilla-central/source/modules/libpref...
- jacobolus 8y ago
  Speed when running in the browser is probably the main practical concern for most folks using wasm....
  - derefr 8y ago
    Some projects are looking forward to using WASM as a general replacement for their current Turing-complete query language engine (e.g. Javascript in CouchDB, Lua in Redis, etc.) WAVM is probably what such systems would embed.
  - inDigiNeous 8y ago
    That and distribution of applications without having to provide the source, although currently you can of course minimize and compile the source, but still it's much more readable than an actual assembly -output.
- kodablah 8y ago
  A post a month ago benchmarked a couple of those you mentioned: https://medium.com/fluence-labs/a-standalone-webassembly-vm-benchmark-7a0f701da3d5 https://medium.com/fluence-labs/a-standalone-webassembly-vm-...
crabl 8y ago
Apple has shown and continues to show willingness to embrace web technologies once they show clear promise or stability[1]. They might not implement "hemorrhaging edge" technologies immediately, but if the technology supports it, and it contributes positively to the user experience, they will do it. [1]: https://twitter.com/mhartington/status/1089292031548145666 https://twitter.com/mhartington/status/1089292031548145666
- endless1234 8y ago
  Apart from stuff that competes with their app store, like web push, of course
  - Vinnl 8y ago
    And Service Workers, though admittedly that implementation took long and is apparently still brittle.
- NicoJuicy 8y ago
  They won't add functionality that would compete with the app store. Add to home screen is a good example
  - baybal2 8y ago
    I think that "add to home screen" is a stupid browser API, serving no genuine technical necessity. Feature creep of browsers must be forcefully stopped.
    - Jedi72 8y ago
      What?? This makes no sense.
      - moreira 8y ago
        It's just about showing a banner to add to home screen, and the person is not wrong — there is no technical necessity for it. There is already, and always has been, an "Add to home screen" button in Safari. Since the very start. Having said that, if PWA support in iOS moves forward I wouldn't be surprised if that API is added to iOS, since then it'd be part of a bigger-picture thing.
dewafont 8y ago
https://dewafont.com/website-and-seo/ https://dewafont.com/website-and-seo/
int_19h 8y ago
I wonder if wasm is feasible to target in hardware. I mean, there were hardware Java bytecode implementations, and that's a lot higher level, so it's definitely possible - but is it worthwhile? Are there any idiosyncrasies in wasm that make it slower than x86 or ARM, that could be fixed if the underlying architecture was more accommodating?
- uasm 8y ago
  > "I wonder if wasm is feasible to target in hardware. I mean, there were hardware Java bytecode implementations, and that's a lot higher level, so it's definitely possible - but is it worthwhile? Are there any idiosyncrasies in wasm that make it slower than x86 or ARM, that could be fixed if the underlying architecture was more accommodating?" You're asking for unified, standardized, cross-vendor hardware + instruction sets. Why not do this other way around though? "Compile" JS to WASM, then to x86/x64. Finally just execute on the bare metal.
  - vanderZwan 8y ago
    Theoretically it would let you ditch a lot of outdated instructions for something a lot simpler, enabling smaller, more efficient (power-wise) hardware.
  - int_19h 8y ago
    Let me rephrase that. Is x86/x64 (or ARM, for that matter) architecture ideal to compile WASM into? Or could a different architecture be designed that would result in better performance?
    - uasm 8y ago
      > "Let me rephrase that. Is x86/x64 (or ARM, for that matter) architecture ideal to compile WASM into? Or could a different architecture be designed that would result in better performance?" I'm sure you could compile WASM into Japanese or French if you had to. Maybe then, our French-native CPUs would finally be able to process "sudo fais moi un sandwich". My point being, you're asking a very broad, very theoretical question. Are CPUs these days not performing well enough for most applications? If so, is it necessarily due to the complex instruction sets powering those platforms?
titzer 8y ago
Chrome and Firefox performance should be closer, at least in Chrome 72 and 73. I think the comparisons may have been done without trap handler support in Chrome (virtual memory tricks for fast memory bounds checks).
- emeryberger 8y ago
  In our experiments with Chrome, we found no difference for SPEC with or without the trap handler.
mgamache 8y ago
WASM will be the default for any non-trivial web apps in the next few years (assuming the DOM access gets addressed). Why would you ship JavaScript of the internet to then get compiled locally? I know there's arguments for JIT, but I don't think they make sense for JavaScript. Also devs hate JavaScript! Okay, I know we don't all hate it and I know it's popular, but really why does TypeScript exist? It's just a rational way to produce JS that hides the silly nature of JS. Now you don't need JS (or TypeScript) choose the language that works best.
- nerdponx 8y ago
  Does WASM reduce (or at least not-increase) payload size? If not, I'm not sure it's worth it unless the performance improvement is really big.
  - mgamache 8y ago
    AFAIK it does reduce the overall size for equivalent code.
  - freeopinion 8y ago
    Yes. WASM reduces the payload size.
  - markdog12 8y ago
    It reduces size, but perhaps more importantly, reduces parsing time, which is crucial, particularly for slow mobile devices.
Veedrac 8y ago
Summary: > Root Cause Analysis and Advice for Implementers: > We conduct a forensic analysis with the aid of performance counter results to identify the root causes of this performance gap. We find the following results: (1) code compiled to WebAssembly yields more loads and stores than native code (2.1× more loads and 2× more stores in Chrome; 1.6× more loads and 1.7× more stores in Firefox). We attribute this to reduced availability of registers, a sub-optimal register allocator, and a failure to effectively exploit a wider range of x86 addressing modes; (2) increased code sizes lead to more instructions being executed and more L1 instruction cache misses; and (3) generated code has more branches due to safety checks for overflow and indirect function calls. A surprisingly large amount of this boils down to "x86 needs more registers", but there's quite a lot of detail here. It validates my personal experience that Chrome doesn't do a very good job relative to Firefox, for example > Code generated by Firefox has 1.15× more branch instructions retired and 1.21× more conditional branch instructions retired than native code, while code generated by Chrome has 4.13× branch instructions retired and 5.06× more conditional branch instructions retired. > Chrome executes 2.9× more instructions and Firefox executes 1.53× more instructions on average than native code. > On average, Chrome suffers from 3.88× more L1 instruction cache misses than native code, and Firefox suffers from 1.8× more L1 instruction cache misses than native code. Overall, it was always obvious that Chrome's deficit compared to Firefox was just engineering work, but what is new is figuring out how difficult the native code deficit would be to close. Some aspects are quite straightforward; browsers probably need to develop a more aggressive tier-2 WASM JIT, now that both listed have a tier-1 baseline that is very fast to compile. This should include: 1. a better register allocator, 2. better peephole optimizations, 3. sophisticated loop optimizations. Unavoidable slowdowns might include: 1. register pressure from reserved registers, 2. stack overflow checks, 3. function table bounds checks. ——— Is this line a typo? I can't make sense of it; I read 1.5 and 1.9 respectively from the table. (There's another mistyped sentence starting ‘Clang,’ but it is not a major issue.) > On average WebAssembly in Firefox runs at 1.9× over native code and in Chrome runs at 1.75× over native code.
- tachyonbeam 8y ago
  This isn't very surprising. C compilers have developed all kinds of low level optimizations over decades, trying to extract the last bits of performance they could. In contrast, JIT compilers for JS focused on recovering missing type information through type inference and other low-hanging fruits. It's also the case that there's a lot more pressure on JS JITs to produce code fast, and so running multiple passes of low level optimizations was not desirable in a web context. This is somewhat bad news for WASM: better low level optimizations could mean longer compilation times. However, AFAIK, Chrome has been working on caching compiled code, so you may only have to compile WASM when it changes (or when you reinstall/update your browser).

250 points by furcyd 8y ago

snek 8y ago

Seems like the tl;dr is that v8 and spidermonkey need to work on adding more optimization tiers to their wasm piplines

roca 8y ago
Another tl;dr is that if you care about WebAssembly performance, use Firefox.
- yodon 8y ago
  > if you care about WebAssembly performance, use Firefox Unless you have customers or want them, because Firefox's market share is generally too small to base your entire business around.
  - realPubkey 8y ago
    I think it was meant that YOU, as a single human being, should use firefox
  - est31 8y ago
    In the old days there were websites using flash or silverlight and they had a screen "in order to use this you must use flash" and for some reason, people did download and install flash so that they could watch the cat videos or whatever.
    - pjmlp 8y ago
      The big difference is that without them they would see a broken square, with Chrome or Safari they would still see it, just a bit slower.
maeln 8y ago
Most performance spec for WASM are not even finished (SIMD, Thread, ...). Doing a benchmark will be interesting when at least SIMD as been properly finished and implemented.
- deleted 8y ago
  [deleted]
Veedrac 8y ago
You don't need ‘more’ tiers per se, because WASM can be fully compiled from the outset. Two tiers should be fine.

pier25 8y ago

I never expected WebAssembly to be as fast as native only to be significantly faster than JavaScript. Considering the popularity of Electron, if WebAssembly does get as fast as native or at least 80% there (and that's a really big if) it would easily become the cross platform language for the vast majority of desktop applications. For mobile we will always be dragged down by Apple and its reticence to embrace web technologies. It's 2019 and we can't even show a add to home screen native banner.

forrestthewoods 8y ago
> can't even show a add to home screen native banner. That sounds like a feature.
- untog 8y ago
  Not really. Progressive Web Apps are a much better model for users than the App Store because they get to use the app immediately then decide later whether they want to keep it on their home screen or not. We've all become very used to the App Store but honestly the experience is pretty crappy.
  - jacobolus 8y ago
    Web apps are inherently mediocre on every platform. There’s enough advantage from being accessible via URL, usable on any device, live updating, etc. to compensate that for many uses. But using web apps daily for any serious work is a huge loss in resource use, usability, polish, ... The one that makes me saddest though is that web apps seem to be getting worse over time. For example most of Google’s suite of web apps were dramatically better a decade ago.
    - onion2k 8y ago
      The problem of mediocre apps is not what they're written in. Millions of people happily use apps built on web technologies every day without even realising. Similarly, millions of people use badly made native apps and hate every second. The tech is not the problem.

theninjagreg 8y ago

The paper is comparing to native. How does it WASM compare to Javascript?

markdog12 8y ago
> We find that while WebAssembly runs faster than JavaScript (on average 1.3× faster across SPEC CPU)

xiphias2 8y ago

Compilation speed should be part of the benchmarks, as it's critical for WebASM. The best would be to use the Clang optimization setting with the most similar compilation speed to compare runtime speeds. As an example the article mentions suboptimal register allocation, but without compile time comparision there's no way to know if there really is a simple way to improve WebGL implementation.

comex 8y ago
It's true that Clang can't compete with the JITs in question on speed. Even at the settings with the most comparable quality of generated code, Clang will be much slower, because its internal design is primarily geared towards maximum optimization potential at high optimization levels, with lower optimization levels as more of an afterthought. But that's beside the point. The paper isn't suggesting switching to Clang or to the algorithms Clang is using. Rather, it's treating Clang's output as an approximation of 'optimal' code generation for the given C code. There are various reasons to compare it to WebAssembly JITs: - For one, the paper identifies specific reasons the JIT output is slower, which shows potential areas of improvement they could focus on. - The comparison also provides a sort of upper bound on how much the JITs theoretically could be improved. It's only a weak upper bound; the upper bound of code quality achievable at the required performance levels is lower and would be more relevant, but there's no way to measure that. - It also indicates the potential of adding a higher tier to the JIT that optimizes very hot code using slower algorithms. - And finally, most entertainingly, the benchmarks help answer age-old questions like "can WebAssembly replace native code?" :) Or, at least, "for what applications can WebAssembly replace native code and have acceptable performance?"...
gpderetta 8y ago
The problem is that the compilation budget is much smaller when it impacts the perceived startup time of the application. For a performance critical application it is much easier to throw resources to offline compilation than for online compilation. Do typical web assembly implementations cache the result of compilation?

hackcasual 8y ago

They disable vectorization on native, so hard to call this a true apples-to-apples comparison

Veedrac 8y ago
It makes sense since WASM's SIMD isn't ready yet, and a paper saying “WASM is slower because SIMD isn't ready yet” would be rather uninformative to browser vendors.
- hackcasual 8y ago
  I think the problem when you're doing X vs. native is you're implicitly saying "X vs. the best possible situation." I think it's fine to compare it against vector-less operations, but they should also benchmark against more vanilla native compiler settings.
  - vanderZwan 8y ago
    > when you're doing X vs. native is you're implicitly saying "X vs. the best possible situation." Not really, any sensible benchmark would be "X vs. the most relevant point of comparison".

quangio 8y ago

The benchmark seems to use only browsers' built in VMs to run WebAssembly (more like the the efficiency of different VM JIT compilers compared to native). How about running them in standalone webassembly VM like WAVM (it does more aggressive optimization, use LLVM for JIT), Asmble (running in JVM), or Wasmer (use Cranelift like Firefox does, maybe a little bit faster than Firefox) (I just skimmed the paper, sorry if i miss something)

est31 8y ago
> use Cranelift like Firefox does To my knowledge, Cranelift in Firefox is still disabled by default. https://searchfox.org/mozilla-central/source/modules/libpref/init/all.js#1483 https://searchfox.org/mozilla-central/source/modules/libpref...
jacobolus 8y ago
Speed when running in the browser is probably the main practical concern for most folks using wasm....
- derefr 8y ago
  Some projects are looking forward to using WASM as a general replacement for their current Turing-complete query language engine (e.g. Javascript in CouchDB, Lua in Redis, etc.) WAVM is probably what such systems would embed.
- inDigiNeous 8y ago
  That and distribution of applications without having to provide the source, although currently you can of course minimize and compile the source, but still it's much more readable than an actual assembly -output.
kodablah 8y ago
A post a month ago benchmarked a couple of those you mentioned: https://medium.com/fluence-labs/a-standalone-webassembly-vm-benchmark-7a0f701da3d5 https://medium.com/fluence-labs/a-standalone-webassembly-vm-...

crabl 8y ago

Apple has shown and continues to show willingness to embrace web technologies once they show clear promise or stability[1]. They might not implement "hemorrhaging edge" technologies immediately, but if the technology supports it, and it contributes positively to the user experience, they will do it. [1]: https://twitter.com/mhartington/status/1089292031548145666 https://twitter.com/mhartington/status/1089292031548145666

endless1234 8y ago
Apart from stuff that competes with their app store, like web push, of course
- Vinnl 8y ago
  And Service Workers, though admittedly that implementation took long and is apparently still brittle.
NicoJuicy 8y ago
They won't add functionality that would compete with the app store. Add to home screen is a good example
- baybal2 8y ago
  I think that "add to home screen" is a stupid browser API, serving no genuine technical necessity. Feature creep of browsers must be forcefully stopped.
  - Jedi72 8y ago
    What?? This makes no sense.
    - moreira 8y ago
      It's just about showing a banner to add to home screen, and the person is not wrong — there is no technical necessity for it. There is already, and always has been, an "Add to home screen" button in Safari. Since the very start. Having said that, if PWA support in iOS moves forward I wouldn't be surprised if that API is added to iOS, since then it'd be part of a bigger-picture thing.

dewafont 8y ago

https://dewafont.com/website-and-seo/ https://dewafont.com/website-and-seo/

int_19h 8y ago

I wonder if wasm is feasible to target in hardware. I mean, there were hardware Java bytecode implementations, and that's a lot higher level, so it's definitely possible - but is it worthwhile? Are there any idiosyncrasies in wasm that make it slower than x86 or ARM, that could be fixed if the underlying architecture was more accommodating?

uasm 8y ago
> "I wonder if wasm is feasible to target in hardware. I mean, there were hardware Java bytecode implementations, and that's a lot higher level, so it's definitely possible - but is it worthwhile? Are there any idiosyncrasies in wasm that make it slower than x86 or ARM, that could be fixed if the underlying architecture was more accommodating?" You're asking for unified, standardized, cross-vendor hardware + instruction sets. Why not do this other way around though? "Compile" JS to WASM, then to x86/x64. Finally just execute on the bare metal.
- vanderZwan 8y ago
  Theoretically it would let you ditch a lot of outdated instructions for something a lot simpler, enabling smaller, more efficient (power-wise) hardware.
- int_19h 8y ago
  Let me rephrase that. Is x86/x64 (or ARM, for that matter) architecture ideal to compile WASM into? Or could a different architecture be designed that would result in better performance?
  - uasm 8y ago
    > "Let me rephrase that. Is x86/x64 (or ARM, for that matter) architecture ideal to compile WASM into? Or could a different architecture be designed that would result in better performance?" I'm sure you could compile WASM into Japanese or French if you had to. Maybe then, our French-native CPUs would finally be able to process "sudo fais moi un sandwich". My point being, you're asking a very broad, very theoretical question. Are CPUs these days not performing well enough for most applications? If so, is it necessarily due to the complex instruction sets powering those platforms?

titzer 8y ago

Chrome and Firefox performance should be closer, at least in Chrome 72 and 73. I think the comparisons may have been done without trap handler support in Chrome (virtual memory tricks for fast memory bounds checks).

emeryberger 8y ago
In our experiments with Chrome, we found no difference for SPEC with or without the trap handler.

mgamache 8y ago

WASM will be the default for any non-trivial web apps in the next few years (assuming the DOM access gets addressed). Why would you ship JavaScript of the internet to then get compiled locally? I know there's arguments for JIT, but I don't think they make sense for JavaScript. Also devs hate JavaScript! Okay, I know we don't all hate it and I know it's popular, but really why does TypeScript exist? It's just a rational way to produce JS that hides the silly nature of JS. Now you don't need JS (or TypeScript) choose the language that works best.

nerdponx 8y ago
Does WASM reduce (or at least not-increase) payload size? If not, I'm not sure it's worth it unless the performance improvement is really big.
- mgamache 8y ago
  AFAIK it does reduce the overall size for equivalent code.
- freeopinion 8y ago
  Yes. WASM reduces the payload size.
- markdog12 8y ago
  It reduces size, but perhaps more importantly, reduces parsing time, which is crucial, particularly for slow mobile devices.

Veedrac 8y ago

Summary: > Root Cause Analysis and Advice for Implementers: > We conduct a forensic analysis with the aid of performance counter results to identify the root causes of this performance gap. We find the following results: (1) code compiled to WebAssembly yields more loads and stores than native code (2.1× more loads and 2× more stores in Chrome; 1.6× more loads and 1.7× more stores in Firefox). We attribute this to reduced availability of registers, a sub-optimal register allocator, and a failure to effectively exploit a wider range of x86 addressing modes; (2) increased code sizes lead to more instructions being executed and more L1 instruction cache misses; and (3) generated code has more branches due to safety checks for overflow and indirect function calls. A surprisingly large amount of this boils down to "x86 needs more registers", but there's quite a lot of detail here. It validates my personal experience that Chrome doesn't do a very good job relative to Firefox, for example > Code generated by Firefox has 1.15× more branch instructions retired and 1.21× more conditional branch instructions retired than native code, while code generated by Chrome has 4.13× branch instructions retired and 5.06× more conditional branch instructions retired. > Chrome executes 2.9× more instructions and Firefox executes 1.53× more instructions on average than native code. > On average, Chrome suffers from 3.88× more L1 instruction cache misses than native code, and Firefox suffers from 1.8× more L1 instruction cache misses than native code. Overall, it was always obvious that Chrome's deficit compared to Firefox was just engineering work, but what is new is figuring out how difficult the native code deficit would be to close. Some aspects are quite straightforward; browsers probably need to develop a more aggressive tier-2 WASM JIT, now that both listed have a tier-1 baseline that is very fast to compile. This should include: 1. a better register allocator, 2. better peephole optimizations, 3. sophisticated loop optimizations. Unavoidable slowdowns might include: 1. register pressure from reserved registers, 2. stack overflow checks, 3. function table bounds checks. ——— Is this line a typo? I can't make sense of it; I read 1.5 and 1.9 respectively from the table. (There's another mistyped sentence starting ‘Clang,’ but it is not a major issue.) > On average WebAssembly in Firefox runs at 1.9× over native code and in Chrome runs at 1.75× over native code.

tachyonbeam 8y ago
This isn't very surprising. C compilers have developed all kinds of low level optimizations over decades, trying to extract the last bits of performance they could. In contrast, JIT compilers for JS focused on recovering missing type information through type inference and other low-hanging fruits. It's also the case that there's a lot more pressure on JS JITs to produce code fast, and so running multiple passes of low level optimizations was not desirable in a web context. This is somewhat bad news for WASM: better low level optimizations could mean longer compilation times. However, AFAIK, Chrome has been working on caching compiled code, so you may only have to compile WASM when it changes (or when you reinstall/update your browser).