Closed
Bug 1052386
Opened 10 years ago
Closed 9 years ago
3% regression in octane-NavierStokes on MacOSX 32bit
Categories
(Core :: JavaScript Engine, defect)
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.
Reporter | ||
Comment 1•10 years ago
|
||
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)
Updated•10 years ago
|
OS: Linux → Mac OS X
Hardware: x86_64 → x86
Comment 3•10 years ago
|
||
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)
Comment 4•10 years ago
|
||
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)
Comment 5•10 years ago
|
||
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)
Reporter | ||
Comment 6•10 years ago
|
||
(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)
Reporter | ||
Comment 7•9 years ago
|
||
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.
Description
•