Closed Bug 647048 Opened 9 years ago Closed 7 years ago

TI: remove perf regressions without -n

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: bhackett1024, Unassigned)

References

(Blocks 1 open bug)

Details

A major prerequisite for type inference to land on tracemonkey is to not have perf regressions when inference is disabled (inference will most likely land default-disabled, and even if it doesn't it would be better to disable it rather than have to back it out for release).
Part 1, fix the obvious places where inference differs from stock JM (regalloc, packed arrays, extra syncs and JSFrameReg accesses around stub calls).

http://hg.mozilla.org/projects/jaegermonkey/rev/0b1dd5e20bb9

This reduces the difference vs. stock -m to 4% (from 10%).  Most of this *should* be from differences in codegen or assorted stupid stuff I need to ferret out --- the non-removable overhead of checking cx->typeInferenceEnabled() and extra dereference to access obj->proto should be pretty puny.

Overhead for stock -m -j -p is 16%, concentrated in a few tests where there is a 2x slowdown, most likely some stupid stuff the branch is doing.
Part 2.

http://hg.mozilla.org/projects/jaegermonkey/rev/baccdc943514

- More robust perf fixage for packed arrays (we want to ensure that if inference is disabled, array->capacity == array->initializedLength)

- Only do one dereference to check cx->typeInferenceEnabled() (inference is enabled per-compartment, now cx caches the bit)

- Speculate that GNAME and NAME calls to Array() are getting the builtin function, and precompute the prototype.  This path is fairly hot in a few SS tests, was about 15% slower in stock JM vs stock TM and 15% slower infer JM vs stock JM (due to extra checks vis a vis type information).  This fixes infer JM and stock JM to be about as fast as stock TM.

- With -mjp, the JM branch is about 1.5% slower than the TM branch on SS, a wash on v8bench.  The gap is a little wider with -m.  I don't think trying to reduce the disabled inference overhead further will be productive, but it should be easy enough to find 3ms of SS gain somewhere else (arithmetic IC with string + string path?)
Depends on: 647463
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.