Firefox 3X slower than Chrome on number game benchmark

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
6 years ago
5 years ago

People

(Reporter: dvander, Assigned: jandem)

Tracking

({perf})

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(1 attachment)

8.50 KB, application/x-javascript
Details
The author of the benchmark sent me an e-mail that it runs significantly slower in Firefox. I tried it on a VM and it does appear to be about 3X slower (tested Nightly vs Canary).
Summary: Firefox 4X slower than Chrome on number game benchmark → Firefox 3X slower than Chrome on number game benchmark
Testcase runs in workers.  Worker-specific issue?
Flags: needinfo?(jdemooij)
I updated the script so the use of workers is optional. While it gets a bit faster, it's only a tiny bit (it gets a tiny bit faster in Chrome that way, too). I use workers so the output can dynamically update and Firefox won't complain about a slow running script.

Btw.: I could not manage to profile the script using workers. Can Firefox do that or do I miss something? I couldn't find such an option in Chrome either.
panzi, thank you.

Looks like the time is in fact mostly in jitcode.  There's a bit of DoUseCountFallback, and js::jit::Compile in the profile.

JIT inspector claims some hot GetPropertyPolymorphicT in function solutions(), but not sure where since it no longer matches up hot blocks to code lines.  :(
panzi: cool website! A long time ago I wrote something similar in Python for a school project. The goal was for very positive integer <= 100 (I think) to find an expression that results in that number, using only the first 5 primes (and we had to use all numbers exactly once) ;)

Looking into this now.
Assignee: general → jdemooij
Posted file Shell testcase
I converted this to a shell testcase and get these numbers:

SM : 3.2 seconds
d8 : 2.9 seconds

So we're still slower but the difference is *much* smaller. For Chrome, there's no difference between the browser and shell.

Either it improved a lot very recently or it's slower in the browser for some reason.
After updating my nightly, it runs in 3.44 seconds (without workers) or 4.11 seconds (with workers). So it does look like something made this a lot faster. Will see if I can find out what exactly.
Without parallel compilation, this is the range where it got faster in the shell:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=77ed46bf4c1a&tochange=ab5f29823236

What's weird though is that with --ion-parallel-compile=on it's fast with all shell builds I tried. That doesn't match what we see in the browser..
I downloaded some inbound builds and it looks like bug 897926 made this fast in the shell without parallel compilation. Looking at the "solutions" function, that seems reasonable.

Still not sure why it didn't affect parallel compilation runs in the shell (but did affect the browser which has parallel compilation enabled).
Depends on: 897926
Flags: needinfo?(jdemooij)
I get 3.15 seconds with a GGC build, still about 300 ms slower than V8. We spend almost all time in JIT code though and I don't see anything obvious. We inline a ton of scripts but most of these are very small.

This probably needs a bunch of small optimizations, like inlining more property gets/sets/adds directly without using IC's.
We're now a bit faster than Chrome:

Workers:

Nightly:       2.122 seconds
Chrome 39 dev: 2.513 seconds

Without workers:

Nightly:       2.166 seconds
Chrome 39 dev: 2.333 seconds
Status: NEW → RESOLVED
Closed: 5 years ago
Keywords: perf
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.