Javascript Performance Thread

Discussion about official Mozilla Firefox builds
Post Reply
h4writer
Posts: 23
Joined: September 13th, 2011, 4:25 pm

Re: Javascript Performance Thread

Post by h4writer »

@Josa, everything I said was correct ;). Indeed for webpages that don't use JS, IM won't make a difference. But the 10.000 usecount limit is not that high. (Note: the usecount is accumulated across calls.) Gmail and facebook definitely hit that ;). Possible perceived improvement will be low, because it is already fast. I mean the bottleneck on those sites are not JS execution speed. But the speed does increase, making it possible for gmail/facebook to do even more fancier things...

As for Ion-eager builds. I definitely wouldn't recommend it. Those builds are slower than JM only! That is because IM compilation is very expensive. That's why IM only kicks in when functions are hot. Only in those cases the runtime of IM compiled code outweight the cost of the expensive compilation. Also type information isn't stable yet and every time there is wrong type information, new code has to get compiled. I.e. making it even worse for, IM.

Also a clarification: IonMonkey doesn't get chosen on a per-application base, but on a javascript function base. Therefore even short running applications can get the benefit of IM. Off course only the hot functions in that application. But as the running time increases, more and more code will be run in IM (as the different functions get hot) and the improvement will increase. That's the reason why IM is targeted at long running applications. Because longer running applications will benefit more ...
irc nick: h4writer #ionmonkey / #jsapi, https://twitter.com/h4writer
Ver Greeneyes
Posts: 1030
Joined: June 28th, 2008, 4:57 am

Re: Javascript Performance Thread

Post by Ver Greeneyes »

Note that JM+TI* will eventually be replaced by a simpler 'baseline compiler', which should be independent of type information and compile very quickly (but forego a lot of the more complicated optimizations). Alongside off main thread compilation, that will probably cause them to readjust the various limits before IM kicks in.

*TI itself isn't going away, mind you, as IM relies on it.
User avatar
Grantius
Posts: 1545
Joined: June 28th, 2011, 4:14 pm
Contact:

Re: Javascript Performance Thread

Post by Grantius »

haytjes wrote:@Josa, everything I said was correct ;). Indeed for webpages that don't use JS, IM won't make a difference. But the 10.000 usecount limit is not that high. (Note: the usecount is accumulated across calls.) Gmail and facebook definitely hit that ;). Possible perceived improvement will be low, because it is already fast. I mean the bottleneck on those sites are not JS execution speed. But the speed does increase, making it possible for gmail/facebook to do even more fancier things...

As for Ion-eager builds. I definitely wouldn't recommend it. Those builds are slower than JM only! That is because IM compilation is very expensive. That's why IM only kicks in when functions are hot. Only in those cases the runtime of IM compiled code outweight the cost of the expensive compilation. Also type information isn't stable yet and every time there is wrong type information, new code has to get compiled. I.e. making it even worse for, IM.

Also a clarification: IonMonkey doesn't get chosen on a per-application base, but on a javascript function base. Therefore even short running applications can get the benefit of IM. Off course only the hot functions in that application. But as the running time increases, more and more code will be run in IM (as the different functions get hot) and the improvement will increase. That's the reason why IM is targeted at long running applications. Because longer running applications will benefit more ...


Thanks for explaining it, makes sense now.
Micro gaming box: AMD A10-7800 APU, 8gb RAM M350 ITX case (size of a book), Windows 10/Ubuntu
Tablet/Laptop: Asus Transformer T100, Intel Atom 2GB RAM, Windows 10 x86
Mobile:Xiaomi Redmi Note 3 Pro
greg86
Posts: 50
Joined: January 28th, 2007, 11:33 am
Location: Germany
Contact:

Re: Javascript Performance Thread

Post by greg86 »

It is now customary that regressions are not fixed?
Especially JM+TI slowed down on all benches, JM+TI+Ion "only" on Sunspider
phuzi0n
Posts: 517
Joined: June 23rd, 2010, 5:48 pm

Re: Javascript Performance Thread

Post by phuzi0n »

greg86 wrote:It is now customary that regressions are not fixed?
Especially JM+TI slowed down on all benches, JM+TI+Ion "only" on Sunspider

They generally don't care much about regressions in an engine that they are in the process of replacing and which does not affect end user performance on its own. JM-TI-Ion is what currently ships and is barely affected by it. With that in mind, it also depends whether the regression was expected and considered an acceptable loss to achieve a greater goal or if it was unexpected.
evilpie
Posts: 55
Joined: December 8th, 2010, 1:23 pm

Re: Javascript Performance Thread

Post by evilpie »

The regression in Kraken and Sunspider across the board was probably caused by source compression (Bug 821040). We plan on fixing this. The regression on JM+TI without Ion was caused by Bug 792108, which is just one piece in reworking the way we implement elements and properties for objects. In the bug we actually decided that it's not worth fixing this in JM, considering that the shipping configuration with Ion enabled does not regress. Which by the way took quite a while to ensure.
bksening
Posts: 26
Joined: December 22nd, 2009, 5:05 pm

Re: Javascript Performance Thread

Post by bksening »

Octane benchmark graph is now on AWFY!
nadark
Posts: 491
Joined: November 12th, 2010, 9:12 am

Re: Javascript Performance Thread

Post by nadark »

Seems we are doing much better on ARM than on x86.
User avatar
KilliK
Posts: 612
Joined: June 18th, 2004, 7:11 am

Re: Javascript Performance Thread

Post by KilliK »

any news in the progression of this technology?
FF18 was accompanied by Mozilla's announcement that it is 25% faster than the previous version but in reality it is still very slow compared to the competition.
A fact which causes some ironic remarks in the comments in various tech sites.

If Mozilla is incapable of at least making their JS engine as fast as their competitors, what's the point to invest so many resources and time on this project?
Two years later and FF gets a beatdown in the benchmarks.
User avatar
Grantius
Posts: 1545
Joined: June 28th, 2011, 4:14 pm
Contact:

Re: Javascript Performance Thread

Post by Grantius »

ominus wrote:any news in the progression of this technology?
FF18 was accompanied by Mozilla's announcement that it is 25% faster than the previous version but in reality it is still very slow compared to the competition.
A fact which causes some ironic remarks in the comments in various tech sites.

If Mozilla is incapable of at least making their JS engine as fast as their competitors, what's the point to invest so many resources and time on this project?
Two years later and FF gets a beatdown in the benchmarks.


What are you talking about? Firefox is one of the faster browsers, and has the least memory usage under load. It isn't FF4 anymore, its a whole new beast.

nadark wrote:Seems we are doing much better on ARM than on x86.


The focus has been on ARM at the moment, so no wonder.
Micro gaming box: AMD A10-7800 APU, 8gb RAM M350 ITX case (size of a book), Windows 10/Ubuntu
Tablet/Laptop: Asus Transformer T100, Intel Atom 2GB RAM, Windows 10 x86
Mobile:Xiaomi Redmi Note 3 Pro
User avatar
KilliK
Posts: 612
Joined: June 18th, 2004, 7:11 am

Re: Javascript Performance Thread

Post by KilliK »

yeah i know that. But here is the JS topic and this is what i am talking about.
Is FF18 truly 25% faster with IonMonkey or is it just bogus marketing from Mozilla?
Josa
Posts: 7364
Joined: July 28th, 2009, 4:52 pm

Re: Javascript Performance Thread

Post by Josa »

Some developers are working on something called asm.js (https://github.com/dherman/asm.js). And it's gonna be integrated on Firefox with the name OdinMonkey, being developed by Luke Wagner on http://hg.mozilla.org/users/lwagner_moz ... nd-patches
User avatar
Grantius
Posts: 1545
Joined: June 28th, 2011, 4:14 pm
Contact:

Re: Javascript Performance Thread

Post by Grantius »

ominus wrote:yeah i know that. But here is the JS topic and this is what i am talking about.
Is FF18 truly 25% faster with IonMonkey or is it just bogus marketing from Mozilla?


Check out arewefastyet.com - It has a comparison chart with IM turned on and off
Micro gaming box: AMD A10-7800 APU, 8gb RAM M350 ITX case (size of a book), Windows 10/Ubuntu
Tablet/Laptop: Asus Transformer T100, Intel Atom 2GB RAM, Windows 10 x86
Mobile:Xiaomi Redmi Note 3 Pro
nadark
Posts: 491
Joined: November 12th, 2010, 9:12 am

Re: Javascript Performance Thread

Post by nadark »

Wondering, is there a benchmark out there that can take advantage of IM's parallel nature? I've seen people talking about IM running on more than 1 core but the benchmarks aren't really showing it, or are the benchmarks simply all single-thread?
Josa
Posts: 7364
Joined: July 28th, 2009, 4:52 pm

Re: Javascript Performance Thread

Post by Josa »

nadark wrote:Wondering, is there a benchmark out there that can take advantage of IM's parallel nature? I've seen people talking about IM running on more than 1 core but the benchmarks aren't really showing it, or are the benchmarks simply all single-thread?

On Kraken I see a 10% speed up with parallel compilation. Gaussian-blur gets 60% faster.
And on Octane I see a 8% speed up.
Post Reply