Closed Bug 1052386 Opened 10 years ago Closed 9 years ago

3% regression in octane-NavierStokes on MacOSX 32bit

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: h4writer, Unassigned)

References

Details

AWFY is reporting a 3% regression in octane-NavierStokes on MacOSX 32bit
http://arewefastyet.com/#machine=11&view=single&suite=octane&subtest=NavierStokes&start=1407780977&end=1407803716

The regression range is:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4d90a2cce157&tochange=2986d8d21bc5

I've instructed AWFY to run on all revisions in the regression range. So in 2-3h those should be visible on the given AWFY graph.
Need info from terrence, since he is the only constant in all these bugs. He has reviewed the patch or created it. When the results come in and we can pinpoint one specific revision, feel free to need-info the actual person.
Flags: needinfo?(terrence)
Bug 1024250 caused this regression.
Blocks: 1024250
OS: Linux → Mac OS X
Hardware: x86_64 → x86
So, I reproduced this locally and it's a bit of an odd case.

* The patch doesn't touch any jitcode and navier-stokes runs entirely in ion.
* The performance difference inverts if I build with --enable-posix-nspr-emulation instead of --enable-nspr-build.
* The performance difference disappears if I build with --disable-threadsafe, although the performance does not change significantly.
* Instruments claims the performance difference is entirely behind a jit address. Likely not the same code in both runs, but the difference doesn't jump out somewhere that /isn't/ jitcode.
* If I kill the new MOZ_ALWAYS_INLINE'd bitmap check in readBarrier, the perf difference goes away.
* Clang on linux (x64) has roughly the same amount of slowdown, but not gcc in x64 or x86.

This certainly seems like a changed inlining or code layout decision.
Flags: needinfo?(terrence)
Also AWFY looks like it's now back to where it was before my patch. I don't see anything that's particularly actionable here; can we close?
Flags: needinfo?(hv1989)
And it's jumped back up in this range:

http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c975c3d3545d&tochange=ee2ce6de3670

At least there's something that touches the jit in there.

Nicolas, do you think that patch is an actual regression, or is just tripping over the same instability I hit?
Flags: needinfo?(nicolas.b.pierron)
(In reply to Terrence Cole [:terrence] from comment #5)
> Nicolas, do you think that patch is an actual regression, or is just
> tripping over the same instability I hit?

That bug of Nicolas has definitely some regressions. Not sure if NavierStokes is one of them. I'll have to test it more closely.

The thing is that NavierStokes tended to be one of the less noisy and reliably benchmarks. So I'm very unhappy if we would also have two performance lines here, that it switches in between. Since performance is back without any change from terrence, I can agree this is not entirely caused his commit. So you are off the hook.

Leaving needinfo from myself to have a closer look.
Flags: needinfo?(nicolas.b.pierron)
Marking this as wontfix. Never found what the real reason was and in between we now have a huge improvement.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(hv1989)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.