Javascript Performance Thread

[andy06]

1. On the 32 bit Sunspider test, JM+TM has been slower than JM all along. Is there still major work to do on heuristics?
How come it is faster on the 64 bit version of the same test? (and indeed in every other benchmark)

2. Once the 15% gains have been achieved and all patches have landed, how much can we expect JM+TM to pull away from JM but pure optimisation and reworking of heuristics?

3. Are there any Spidermonkey bits (interpreter?) still involved or that's been totally depreciated?

[mattcoz]

1. On the 32 bit Sunspider test, JM+TM has been slower than JM all along. Is there still major work to do on heuristics?

http://arewefastyet.com/faq.html

Why is the JM+TM line slower than JM on SunSpider?

We're working on this - see bug 580468. The deal is that SunSpider is very short running, as it was developed before any JavaScript JITs existed. Trace compilation usually works best on longer running benchmarks. We'll have heuristics to make sure the right JIT comes into play at the right time.

[mat--]

Looks like the surgery is complete.

http://www.youtube.com/watch?v=A9kvT1zhP_A

[phuzi0n]

2. Once the 15% gains have been achieved and all patches have landed, how much can we expect JM+TM to pull away from JM but pure optimisation and reworking of heuristics?

3. Are there any Spidermonkey bits (interpreter?) still involved or that's been totally depreciated?

Tuning heuristics is going to be one of the major ways they reach that 15% improvement. Look in the past couple pages of this thread.

The heuristics bug explains how the latest patch works. TM depends on the interpreter which hasn't changed. They may eventually redesign it to be able to trace off of JM's code but for FF4 it will just be using heuristics to guess when a loop will be faster to trace and switching to TM if it thinks it will be worth it.

It hooks into the interpreter in the same way that the trace recorder does.
When a loop has executed enough iterations in the method JIT, we switch to the
interpreter to profile it for one iteration. Profiling keeps track of which
opcodes are executed and the types of the operands. It also tries to predict
the eventual branchiness of the trace. When it's done, it decides whether the
trace is likely to do well based on some of the same factors as in the last
patches:

https://bugzilla.mozilla.org/show_bug.cgi?id=580468#c42

Also this article explains a lot about how TM works.
http://hacks.mozilla.org/2009/07/tracemonkey-overview/

[WonderCsabo]

Looks like the surgery is complete.

?

[phuzi0n]

Looks like the surgery is complete.

?

Brain transplants landed to the TM branch.

[WonderCsabo]

Ah... It's too early on the morning here.

Another question:

The current AWFY latest data point always shows the current latest-tracemonkey build?

Or they are testing that with some newer only-for-devs builds?

[Pillum]

@WonderCsabo
The former...

[WonderCsabo]

Thanks. So the brain translants are not on AFWY, yet.

[Pillum]

The regress-x86 site shows the latest tracemonkey build with brain transplants (9cb987478e60) but the other's not which is a few days old build.

[WonderCsabo]

So with brain transplants the speed is worse? :S

x86 oct 8: 391 ms
regress-x86 oct 10: 394 ms

[Pillum]

You can't compare them both, cause you compared x86 tm+jm with regress-x86 tm/jm and the speed regress could be caused by anything else (many things changed in this 2 days).

[phuzi0n]

They just passed the 400ms mark for SS on the main page even though the regress page has worse numbers for the same revision. They've now met the original 400ms / 2300ms goals!

I pointed this out 2 days ago. The main page showed better performance on the Oct 8th revision than the same exact revision on the regress page showed (hover over points to see the rev). To compare brain transplants just look at the regress page and see that it improved performance over the Oct 8-9th builds.

[Omega X]

Its a 3ms difference. It doesn't matter.

[bzbarsky]

Its a 3ms difference. It doesn't matter.

That's not quite true. Most of the improvement has been 3-6ms differences over an over and over again. A few hundred of them.