Closed Bug 1513189 Opened 6 years ago Closed 3 years ago

No Ion on ARM64 makes asm.js very slow

Categories

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

Product:
Core
Component:
JavaScript Engine: JIT
Platform:
ARM64
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox65 --- wontfix
firefox66 --- fix-optional

People

(Reporter: lth, Assigned: lth)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [arm64:m3])

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.)
[arm64:m1] because we should probably fix, or at least diagnose, this ARM64 baseline issue before pushing ARM64 Fennec Nightly builds to users.
status-firefox66: --- → affected
Whiteboard: [arm64:m1]
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?
status-firefox65: --- → affected
Component: JavaScript Engine: JIT → Javascript: Web Assembly
Flags: needinfo?(lhansen)
Priority: -- → P1
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.
Component: Javascript: Web Assembly → JavaScript Engine: JIT
Flags: needinfo?(lhansen)
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.
No longer blocks: arm64-baseline
Flags: needinfo?(cpeterson)
Priority: P1 → --
Summary: Likely ARM64 JS Baseline bug when running zlib octane benchmark → No Ion on ARM64 makes asm.js very slow
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.
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.
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.
status-firefox65: affected → wontfix
Flags: needinfo?(cpeterson)
Whiteboard: [arm64:m1] → [arm64:m3]

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.

status-firefox66: affected → fix-optional
Priority: -- → P2

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).

Flags: needinfo?(lhansen)

(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.

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.

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.

Flags: needinfo?(lhansen)

This should be fixed now, will verify.

Assignee: nobody → lhansen
Blocks: wasm-jit-bugs

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.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.