870627 - Slow performance on GWT benchmarks

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Alon Zakai (:azakai)]

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]]

Attachment: 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]]

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]]

To be exact we are missing a Native[Int32] getelem

Comment 4

[Luke Wagner [:luke]]

After bug 870814, what is the perf here?

Comment 5

[Hannes Verschore [:h4writer]]

(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]]

(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]]

(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]]

               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]]

Attachment: shell-binarytrees.js

Comment 10

[Guilherme Lima]

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

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 12

[Matthew Gaudet (he/him) [:mgaudet]]

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