The default bug view has changed. See this FAQ.

Slow performance on GWT benchmarks

NEW
Unassigned

Status

()

Core
JavaScript Engine
4 years ago
a year ago

People

(Reporter: azakai, Unassigned)

Tracking

(Depends on: 3 bugs)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
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.
Created attachment 747941 [details]
shell-linpack.js

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

Comment 4

4 years ago
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
Created attachment 757843 [details]
shell-binarytrees.js
(Assignee)

Updated

3 years ago
Assignee: general → nobody

Comment 10

2 years ago
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
You need to log in before you can comment on or make changes to this bug.