Closed
Bug 511737
Opened 15 years ago
Closed 15 years ago
TM: fast path for writing a double into an array
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta1-fixed |
People
(Reporter: gal, Assigned: gal)
Details
(Whiteboard: fixed-in-tracemonkey)
Attachments
(1 file)
3.23 KB,
patch
|
dvander
:
review+
|
Details | Diff | Splinter Review |
4ms speedup on SS. Its a 2% speedup or so for about a third of the test cases. I renew my call for more profiling.
Assignee | ||
Comment 1•15 years ago
|
||
Assignee: general → gal
Assignee | ||
Updated•15 years ago
|
Attachment #395665 -
Flags: review?(dvander)
Updated•15 years ago
|
Attachment #395665 -
Flags: review?(dvander) → review+
Comment 2•15 years ago
|
||
:) nice work
Comment 3•15 years ago
|
||
(In reply to comment #0) > 4ms speedup on SS. I don't trust SS's results enough to present them as definitively as that. I have regularly seen changes that should not affect performance at all ~5ms variation, presumably due to slightly different code layouts causing different interactions with caches, branch predictors, etc. I don't trust any optimisation until I've seen it give a speed-up on at least two configurations (eg. I 'hg pull -u' and the speed-up is still present). And even on a single configuration, using --runs=100 on my Mac I often see variations of 2--3ms from run to run.
Assignee | ||
Comment 4•15 years ago
|
||
Yes, our benchmarks are pretty lame. Yes, we discuss that in every other bug. The patch removes a bunch of spilling between two function calls in LIR and allows GCC to inline the box code into the array set path. Except if those instructions are all free (along with the memory access hat happens), I am pretty confident that this is N cycles faster than before. Can we agree at least on that?
Comment 5•15 years ago
|
||
(In reply to comment #4) > Can we agree at least on that? Sure :)
Comment 6•15 years ago
|
||
should be easy to write a microbenchmark to prove out this optimization, if we want to do that.
Comment 7•15 years ago
|
||
(In reply to comment #6) > should be easy to write a microbenchmark to prove out this optimization, if we > want to do that. I was about to suggest that. Or taking the SS benchmark that is most improved by this patch and increasing the run length by 10-100x.
Assignee | ||
Comment 8•15 years ago
|
||
test case: var a = []; for (var i = 0; i < 10000000; ++i) a[1] = 1.5; without: real 0m0.522s user 0m0.392s sys 0m0.127s with: real 0m0.477s user 0m0.346s sys 0m0.126s
Assignee | ||
Comment 9•15 years ago
|
||
I added a missing INT_FITS_INTO_JSVAL. Pushing with that.
Assignee | ||
Comment 10•15 years ago
|
||
http://hg.mozilla.org/tracemonkey/rev/21b21088c0ef
Whiteboard: fixed-in-tracemonkey
Comment 11•15 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/21b21088c0ef
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 12•15 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/6f2279d24162
status1.9.2:
--- → beta1-fixed
Flags: wanted1.9.2+
You need to log in
before you can comment on or make changes to this bug.
Description
•