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,
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]
That is indeed bad! I created a shell version for the worst of the four. (Haven't look into the reason yet)
- 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
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 ;)
(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
(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 !!
binary trees 14.7
So Binary trees hasn't improved. linpack/meteor improved substantially. And nbody is now faster than chrome.
Created attachment 757843 [details]
I just tested this:
fx - 7.878s
ch - 0.936s
fx - 2.21s
ch - 40.65s [??]
fx - 0.674s
ch - 0.393s
fx - 2.562s
ch - 3.029s