Javascript Performance Thread

Discussion about official Mozilla Firefox builds
Post Reply
User avatar
Grantius
Posts: 1545
Joined: June 28th, 2011, 4:14 pm
Contact:

Re: Javascript Performance Thread

Post by Grantius »

Will they be splitting off JIT compilation to its own process ala IE9+ or leaving it per content process?
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
Ver Greeneyes
Posts: 1030
Joined: June 28th, 2008, 4:57 am

Re: Javascript Performance Thread

Post by Ver Greeneyes »

No idea to be honest; separate processes weren't mentioned, but the conversation didn't go into a lot of detail. I suppose I could try asking - right now I'm just waiting for bugs to be filed to provide more insight.
mayankleoboy1
Posts: 471
Joined: February 25th, 2013, 9:52 pm

Re: Javascript Performance Thread

Post by mayankleoboy1 »

Ver Greeneyes wrote: Sort of. Nicolas Pierron (:nbp) explained on IRC that the idea is to split compilation workloads across multiple threads. He has some slides for it (I haven't seen them), but right now it's still in the conceptual stage as far as I know - no code has been written yet.
any relation to https://bugzilla.mozilla.org/show_bug.cgi?id=785905 , which eventually got backed outg and never landed ?
(I know u r not the right person to ask, but you do hang out in the IRC :P )
Ver Greeneyes
Posts: 1030
Joined: June 28th, 2008, 4:57 am

Re: Javascript Performance Thread

Post by Ver Greeneyes »

Not that I know of - it might just be splitting the parts that are already off the main threads into multiple parts. I do think people would like to see IonBuilder off the main thread again at some point though - it was just too much pain at the time.
h4writer
Posts: 23
Joined: September 13th, 2011, 4:25 pm

Re: Javascript Performance Thread

Post by h4writer »

mayankleoboy1 wrote:
Ver Greeneyes wrote: Sort of. Nicolas Pierron (:nbp) explained on IRC that the idea is to split compilation workloads across multiple threads. He has some slides for it (I haven't seen them), but right now it's still in the conceptual stage as far as I know - no code has been written yet.
any relation to https://bugzilla.mozilla.org/show_bug.cgi?id=785905 , which eventually got backed outg and never landed ?
(I know u r not the right person to ask, but you do hang out in the IRC :P )
It is not related. It would be awesome to have IonBuilder/MIR creation offthread, but currently we have no path forward for this.
The gains don't outweigh the complexity this would add, currently.

IIUC the idea nbp has, is 3 separate ideas he wants to try. (3-headed). With one being about utilizing more threads per compilation unit. Another improving data structure and access to L2 caches. And another one I don't remember anymore. Keep in mind this is quite exploratory.
irc nick: h4writer #ionmonkey / #jsapi, https://twitter.com/h4writer
mayankleoboy1
Posts: 471
Joined: February 25th, 2013, 9:52 pm

Re: Javascript Performance Thread

Post by mayankleoboy1 »

h4writer wrote: Another improving data structure and access to L2 caches. And another one I don't remember anymore. Keep in mind this is quite exploratory.
Is this https://bugzilla.mozilla.org/show_bug.cgi?id=1229043 and its dependents?
h4writer
Posts: 23
Joined: September 13th, 2011, 4:25 pm

Re: Javascript Performance Thread

Post by h4writer »

mayankleoboy1 wrote:
h4writer wrote: Another improving data structure and access to L2 caches. And another one I don't remember anymore. Keep in mind this is quite exploratory.
Is this https://bugzilla.mozilla.org/show_bug.cgi?id=1229043 and its dependents?
I think bug 1229043 spurred his interest to go deeper into this issue. But that bug only speaks about reg allocator.
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 »

Not strictly a JS performance enhancement, but bug 1052793 finally landed, which (if it sticks this time) should greatly reduce the amount of full GCs triggered by the cycle collector - and as a result, potentially make the browser a lot less janky! This was backed out last time for regressing memory usage, but that should be fixed now.
Ver Greeneyes
Posts: 1030
Joined: June 28th, 2008, 4:57 am

Re: Javascript Performance Thread

Post by Ver Greeneyes »

Jan de Mooij just filed a bug (with patch) to unify IC generation for Baseline and Ion. As he explains in the bug, Baseline and Ion ICs currently share very little code, have different limitations and a lot of boilerplate. As a result, it's too easy to introduce errors in one of the two, it's too hard to introduce new ones, and they generally don't take care of all edge cases, leading to performance cliffs. Jan's patch adds a new, simple bytecode that can be used by both JITs to generate the same ICs - letting Baseline quickly generate its infallible code, and Ion generate its more optimized code from the same information.

I'm not sure how much this overlaps with Hannes Verschore's (h4writer) shared stubs work (which are now on by default, but not yet implemented for every IC) - perhaps it leverages the same infrastructure. Either way it should make ICs much more robust, less prone to error and, in some cases, even faster.

Also, this didn't move the needle on any benchmarks, but I recently simplified the way the GC allocates objects from Arenas in bug 1250634 and bug 1251833. I'm happy with how it turned out, and it gave me some ideas for giving the GC its own malloc implementation (which might well improve allocation performance - if it pans out).
mayankleoboy1
Posts: 471
Joined: February 25th, 2013, 9:52 pm

Re: Javascript Performance Thread

Post by mayankleoboy1 »

https://bugzilla.mozilla.org/show_bug.cgi?id=1255008

there is this.
mostly a regression on octane, till now.
mayankleoboy1
Posts: 471
Joined: February 25th, 2013, 9:52 pm

Re: Javascript Performance Thread

Post by mayankleoboy1 »

Ver Greeneyes wrote:
I'm not sure how much this overlaps with Hannes Verschore's (h4writer) shared stubs work (which are now on by default, but not yet implemented for every IC)
Why wouldnt he/they implement it for every IC ?

:nbp did work on resume instructions. Last I remember, the meta-bug still had many instructions which werent "converted" to resume. Why wouldnt he/they implement it for every instruction ?
https://bugzilla.mozilla.org/show_bug.cgi?id=1003801
Ver Greeneyes
Posts: 1030
Joined: June 28th, 2008, 4:57 am

Re: Javascript Performance Thread

Post by Ver Greeneyes »

mayankleoboy1 wrote:https://bugzilla.mozilla.org/show_bug.cgi?id=1255008

there is this.
mostly a regression on octane, till now.
Oh, I meant to mention that one but forgot! Yes, Hannes is working on improving the alias analysis, which IIUC should allow for more loads and stores to be removed. That patch is still in a fairly early stage, and it looks like it needs to be more complete before performance becomes on par with the current implementation - but the information it generates is already better.
mayankleoboy1 wrote:Why wouldnt he/they implement it for every IC ?
He said he could probably knock the rest out in about a day, but I think he's holding off to see how jandem's work pans out.
mayankleoboy1 wrote::nbp did work on resume instructions. Last I remember, the meta-bug still had many instructions which werent "converted" to resume. Why wouldnt he/they implement it for every instruction ?
These are probably more work, and I don't think :nbp was ever officially part of the JS team (maybe he is now that the focus on B2G is less) so I suppose he had other priorities. Also, all the high value ones might be done, but that's just a guess really. Oh, and I think you're conflating 'resume points' and 'recover instructions', which are two different things ;) (IIRC recover instructions allow one to remove resume points)
Ver Greeneyes
Posts: 1030
Joined: June 28th, 2008, 4:57 am

Re: Javascript Performance Thread

Post by Ver Greeneyes »

Feeling a bit drained at the moment, so just a quick note: Jon Coppeard, who wrote SpiderMonkey's compacting GC, has recently been extending its capabilities. Previously, only JSObjects could be compacted. Bug 1257903, which just landed, adds support for shapes - and bug 1258453 adds support for strings. Together, they greatly enhance the capability of compacting GC to minimize wasted space!
Harsh86
Posts: 94
Joined: August 23rd, 2004, 4:34 am

Re: Javascript Performance Thread

Post by Harsh86 »

Ver Greeneyes wrote:Not strictly a JS performance enhancement, but bug 1052793 finally landed, which (if it sticks this time) should greatly reduce the amount of full GCs triggered by the cycle collector - and as a result, potentially make the browser a lot less janky! This was backed out last time for regressing memory usage, but that should be fixed now.
I'd been watching that bug for while too. Terrance Cole recently posted that after landing this enhancement, telemetry figures have improved as such:
"Median GC_MS seems to have gone from 185ms to 150ms. More importantly, the 95th percentile numbers have gone from 1s down to 0.85s."
Ver Greeneyes wrote:Feeling a bit drained at the moment, so just a quick note: Jon Coppeard, who wrote SpiderMonkey's compacting GC, has recently been extending its capabilities. Previously, only JSObjects could be compacted. Bug 1257903, which just landed, adds support for shapes - and bug 1258453 adds support for strings. Together, they greatly enhance the capability of compacting GC to minimize wasted space!
These look like pretty big wins, thanks for keeping us informed. Here are some test results from the respective bugs:
Compact Shapes:
"Test results from my main profile of about 50 tabs. Unused heap occupied by shapes decreases from ~15MB to 0.3MB for a 293MB heap after compacting."

Compact Strings:
"Some numbers from about:memory before and after compacting showing unused space in string arenas reduced from 15.75MB -> 1.26MB for a 220MB heap."
mayankleoboy1
Posts: 471
Joined: February 25th, 2013, 9:52 pm

Re: Javascript Performance Thread

Post by mayankleoboy1 »

any work going on for https://bugzilla.mozilla.org/show_bug.cgi?id=1232802 ? (ConcurrentGC)
Post Reply