The default bug view has changed. See this FAQ.

TI+JM: v8-richards performance regression

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: jandem, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
Score with -n -m went from 5400 to 4200 points. This is a regression from http://hg.mozilla.org/projects/jaegermonkey/rev/f1f907de8765, bug 649376.
A couple performance fixes for richards.

Allow generation of native and full call stubs at ICs within inlined frames.  We didn't do this before because of some extra complexity it brings to inline frame expansion (also, before the interpoline this wasn't really possible for native stubs).  Without this, we were taking a slow call at the 'this.task.run' in 'TaskControlBlock.prototype.run,' which really killed perf.  Fixing this brings JM+TI about even with JM+TM.

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

Constant fold 'x != null' type comparisons where the 'x' cannot be null or undefined.  Previously we stubbed these.  There are a few pretty hot cases of this, in Scheduler.prototype.{queue,release}.

http://hg.mozilla.org/projects/jaegermonkey/rev/12b2b8e6d6d0

This leaves scores for me at:

d8: 12031
js -m -n: 7375
js -m -j -p: 6460

Will file a separate bug for tracking richards perf improvements, there's still a lot left to do here.  Richards does very little allocation, the gap between engines is due to compiler optimizations and codegen.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.