914342 - Firefox 3X slower than Chrome on number game benchmark

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[David Anderson [:dvander] - inactive, e-mail if emergency]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

Testcase runs in workers.  Worker-specific issue?

Comment 2

[Mathias Panzenböck]

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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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

Comment 4

[Jan de Mooij [:jandem]]

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.

Comment 5

[Jan de Mooij [:jandem]]

Attachment: 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.

Comment 6

[Jan de Mooij [:jandem]]

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.

Comment 7

[Jan de Mooij [:jandem]]

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

Comment 8

[Jan de Mooij [:jandem]]

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

Comment 9

[Jan de Mooij [:jandem]]

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.

Comment 10

[Jan de Mooij [:jandem]]

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