1513189 - No Ion on ARM64 makes asm.js very slow

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect, P2)

Description

[Lars T Hansen [:lth]]

This morning I ran some benchmarks in order to assess whether the JS baseline compiler performs about the same on ARM64 as on X64, see writeup on methodology and results here: https://docs.google.com/spreadsheets/d/1nyUDioN48DUw5S7YdIMTq1iQC5oiyGJl8PBYtiuSCmc.

Overall things look just fine, with most benchmarks performing on ARM64 about as well as expected, given the observed difference in the performance of the two test systems.

However, the zlib benchmark is a very strong outlier, taking over an order of magnitude longer to finish on ARM64 than it is expected to.  If we assume that the x64 code is correct, this suggests that there is probably a bug in the JS baseline compiler (or interpreter) for arm64; at least this needs investigation.  (Whether performance bug or functional bug is impossible to say right now, I don't know how well Octane checks its output.)

Comment 1

[Chris Peterson [:cpeterson]]

[arm64:m1] because we should probably fix, or at least diagnose, this ARM64 baseline issue before pushing ARM64 Fennec Nightly builds to users.

Comment 2

[Nicolas B. Pierron [:nbp]]

As far as I know, octane/zlib is targetting Asm.js, so this might be an issue within WASM Baseline ARM64 backend.
Lars, are you investigating Rabaldr ARM64 issues?

Comment 3

[Lars T Hansen [:lth]]

Ah, that explains it!  We don't use Rabaldr for asm.js, so if Ion is not available this is probably asm.js being run as baseline-compiled JS.  No wonder it's slow.

I'll look into this in the morning, to verify that it's right.

I guess if Ion is not finished in time there's a risk to asm.js content in general, then.  Don't know how important that is.

Comment 4

[Lars T Hansen [:lth]]

OK, this is definitely caused by the lack of Ion support, so asm.js runs as baseline-compiled JS.  To simulate the ARM64 situation I had IonCanCompile() return false and I ran with --no-ion.  (asm.js compilation ignores both --no-ion and --no-wasm-ion.)  In this case, the program takes 20x longer to finish on x64 as well.

Clearing the priority since this needs reprioritization.

Clearing the blocker since this probably should block something else, after somebody decides how important asm.js support really is.

In principle, if Ion is starting to look like a risky bet at some point, we could probably support asm.js with the wasm baseline compiler.  It's easier to do that now than it used to be; in the past we had special asm.js support for atomics and simd, but that's all gone.  That said, I don't know how much work it actually is, I suspect there are some corner cases that may be a bit of work.  And it would be nice if we don't have to.

Comment 5

[Lars T Hansen [:lth]]

Trivia: with IonCanCompile always returning false, but without --no-ion, the slowdown is only 3x.  This suggests that somebody ignores the result of IonCanCompile, or doesn't call it at all, to determine whether Ion should be used.

Comment 6

[Lars T Hansen [:lth]]

And to put my previous comment into context: if we have Ion for JS but not for Wasm, then asm.js content will be executed as Ion-compiled JS, which will be slower than if it is executed as translated wasm.  It's a little hard to say how much slower though we may be able to estimate that by just running some code with --no-asmjs, I'm guessing 3x is not far off.  That code will also be subject to other kinds of effects, like js opt/deopt and code GC.

Comment 7

[Chris Peterson [:cpeterson]]

No Ion for asm.js probably doesn't need to block releasing ARM64 Fennec (assuming asm.js content is less common on mobile than on desktop), but Firefox for ARM64 Windows might care more.

Comment 8

[Nicolas B. Pierron [:nbp]]

Setting P2, as this is not one of the first priority of ARM64 port, but we do not want to leave this question unanswer for too long either.

Comment 9

[Chris Peterson [:cpeterson]]

Lars, is asm.js perf still an issue on ARM64 now that we've shipped ARM64 Ion?

I'm wondering when we can re-enable the Unity WebGL tests on ARM64 (bug 1518882).

Comment 10

[Nicolas B. Pierron [:nbp]]

(In reply to Chris Peterson [:cpeterson] from comment #9)

[…] now that we've shipped ARM64 Ion?

We have shipped ARM64 Ion?

AFAIK, It is enabled only on Firefox 68 beta & nightly and nothing more.
Also, my understanding is that we basically have highly limited number of users on ARM64 until we release Fenix with ARM64 enabled, and move Firefox for Android population over to Fenix.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

We're shipping native ARM64 builds of Fennec via Google Play as of Fennec 68. We're also shipping Windows AArch64 builds, though I'm not sure how officially-supported those are yet.

Comment 12

[Lars T Hansen [:lth]]

Chris, ion-on-ARM64 can only compile asm.js as JS and that is known to generate slower code than the asm.js pipeline through wasm+ion. See comment 6, which guesses that asm.js through js+ion is 3x slower than wasm+ion.

Comment 13

[Lars T Hansen [:lth]]

This should be fixed now, will verify.

Comment 14

[Lars T Hansen [:lth]]

Go to https://wellcaffeinated.net/demos/asm-js-physics.html with default setting on an m1, set the number of particles to 600, observe the performance for a little while.

In about:config, set javascript.options.asmjs to false. Reload the test page, make sure the number of particles is still 600, observe that the animation is (somewhat) slower.

Conclusion: asmjs beats ion-compiled JS.