Last Comment Bug 870627 - Slow performance on GWT benchmarks
: Slow performance on GWT benchmarks
Status: NEW
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: x86_64 Linux
: -- normal with 10 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jason Orendorff [:jorendorff]
Mentors:
Depends on: 874882 875137 875225 774006 870814 879168
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-09 17:13 PDT by Alon Zakai (:azakai)
Modified: 2015-12-30 22:54 PST (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
shell-linpack.js (54.27 KB, application/javascript)
2013-05-10 06:23 PDT, Hannes Verschore [:h4writer]
no flags Details
shell-binarytrees.js (53.52 KB, application/javascript)
2013-06-04 01:22 PDT, Hannes Verschore [:h4writer]
no flags Details

Description Alon Zakai (:azakai) 2013-05-09 17:13:36 PDT
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.
Comment 1 Hannes Verschore [:h4writer] 2013-05-10 06:23:37 PDT
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)
Comment 2 Hannes Verschore [:h4writer] 2013-05-10 06:49:11 PDT
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...
Comment 3 Hannes Verschore [:h4writer] 2013-05-10 07:43:33 PDT
To be exact we are missing a Native[Int32] getelem
Comment 4 Luke Wagner [:luke] 2013-05-16 18:15:38 PDT
After bug 870814, what is the perf here?
Comment 5 Hannes Verschore [:h4writer] 2013-05-17 02:27:52 PDT
(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 ;)
Comment 6 Hannes Verschore [:h4writer] 2013-05-22 06:59:45 PDT
(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
Comment 7 Hannes Verschore [:h4writer] 2013-05-22 07:01:06 PDT
(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 !!
Comment 8 Hannes Verschore [:h4writer] 2013-06-03 06:24:30 PDT
               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.
Comment 9 Hannes Verschore [:h4writer] 2013-06-04 01:22:44 PDT
Created attachment 757843 [details]
shell-binarytrees.js
Comment 10 Guilherme Lima 2015-05-30 15:44:25 PDT
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

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