Open Bug 870627 Opened 12 years ago Updated 1 year ago

Slow performance on GWT benchmarks

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect

Tracking

()

People

(Reporter: azakai, Unassigned)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

Attachments

(2 files)

https://dl.dropboxusercontent.com/u/80664946/gwt.tar.bz2 has 4 GWT-compiled benchmarks (run "benchmark.html" in each directory, and see results in the web console). Firefox (nightly) does far worse than chrome (dev), by more than an order of magnitude in most of them, firefox chrome binary trees 11.96 0.57 seconds linpack 56.03 1.06 meteor 1.82 0.26 nbody 63.78 6.72 And even on the best one there is a 7x slowdown.
Attached file shell-linpack.js (deleted) —
That is indeed bad! I created a shell version for the worst of the four. (Haven't look into the reason yet)
linpack: - interp: 27s - baseline: 8s - ion: 50s That definitely looks like a fault in IM. Quick check shows that we are losing a lot of time in GetElementIC::update. Looks like most caches are disabled. So we are missing an IC for something...
To be exact we are missing a Native[Int32] getelem
Depends on: 870814
After bug 870814, what is the perf here?
(In reply to Luke Wagner [:luke] from comment #4) > After bug 870814, what is the perf here? No need to remeasure. Still way too slow ;). (At best this patch improves the scores with 30%). I don't know how much is related to the fact we use a ic cache instead of specific slotloads. But I think that will bring another improvement. That's on my todo list ;)
Depends on: 774006
(In reply to Hannes Verschore [:h4writer] from comment #5) > I don't know how much is related to the fact we use a > ic cache instead of specific slotloads. Jan suggested to look to baseline caches to decide when to use slotloads. This didn't yield an improvement. Maybe
Depends on: 874882
(In reply to Hannes Verschore [:h4writer] from comment #6) > Jan suggested to look to baseline caches to decide when to use slotloads. > This didn't yield an improvement. Maybe Scratch that comment. This does increase performance. That's the reason I added that depending bug ;). Getting close to v8 performance now !!
Depends on: 875137
Depends on: 875225
nightly binary trees 14.7 linpack 3.22 meteor 0.512 nbody 4.093 So Binary trees hasn't improved. linpack/meteor improved substantially. And nbody is now faster than chrome.
Depends on: 879168
Attached file shell-binarytrees.js (deleted) —
Assignee: general → nobody
I just tested this: binary trees fx - 7.878s ch - 0.936s linpack fx - 2.21s ch - 40.65s [??] meteor fx - 0.674s ch - 0.393s nbody fx - 2.562s ch - 3.029s
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 11 votes.
:sdetar, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(sdetar)
Flags: needinfo?(sdetar)

Measuring the benchmark in Comment 1 today on my M1 MBP I find SM is 30% behind v8,

Blocks: jsperf
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: