MozillaZine

Javascript Performance Thread

Discussion about official Mozilla Firefox builds
haytjes
 
Posts: 20
Joined: September 13th, 2011, 4:25 pm

Post Posted December 10th, 2012, 8:34 am

@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: 853
Joined: June 28th, 2008, 4:57 am

Post Posted December 10th, 2012, 9:38 am

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.

Grantius

User avatar
 
Posts: 1328
Joined: June 28th, 2011, 4:14 pm

Post Posted December 10th, 2012, 12:40 pm

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), Ubuntu 15.04/W10TP
Tablet/Laptop: Asus Transformer T100, Intel Atom 2GB RAM, Windows 10TP x86, Nightly 32bit
Mobile:Note 3 with CM12, Nightly FF

greg86
 
Posts: 45
Joined: January 28th, 2007, 11:33 am
Location: Germany

Post Posted December 19th, 2012, 11:14 am

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

Post Posted December 19th, 2012, 11:46 am

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

Post Posted December 20th, 2012, 12:56 pm

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: 25
Joined: December 22nd, 2009, 5:05 pm

Post Posted January 19th, 2013, 11:02 am

Octane benchmark graph is now on AWFY!

nadark
 
Posts: 491
Joined: November 12th, 2010, 9:12 am

Post Posted January 20th, 2013, 9:55 am

Seems we are doing much better on ARM than on x86.

KilliK

User avatar
 
Posts: 538
Joined: June 18th, 2004, 7:11 am

Post Posted January 20th, 2013, 11:01 am

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.

Grantius

User avatar
 
Posts: 1328
Joined: June 28th, 2011, 4:14 pm

Post Posted January 20th, 2013, 11:31 am

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), Ubuntu 15.04/W10TP
Tablet/Laptop: Asus Transformer T100, Intel Atom 2GB RAM, Windows 10TP x86, Nightly 32bit
Mobile:Note 3 with CM12, Nightly FF

KilliK

User avatar
 
Posts: 538
Joined: June 18th, 2004, 7:11 am

Post Posted January 20th, 2013, 12:11 pm

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: 853
Joined: July 28th, 2009, 4:52 pm

Post Posted January 20th, 2013, 12:13 pm

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

Grantius

User avatar
 
Posts: 1328
Joined: June 28th, 2011, 4:14 pm

Post Posted January 20th, 2013, 12:53 pm

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), Ubuntu 15.04/W10TP
Tablet/Laptop: Asus Transformer T100, Intel Atom 2GB RAM, Windows 10TP x86, Nightly 32bit
Mobile:Note 3 with CM12, Nightly FF

nadark
 
Posts: 491
Joined: November 12th, 2010, 9:12 am

Post Posted January 20th, 2013, 3:56 pm

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: 853
Joined: July 28th, 2009, 4:52 pm

Post Posted January 20th, 2013, 4:51 pm

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.

Return to Firefox Builds


Who is online

Users browsing this forum: No registered users and 6 guests