Closed Bug 771738 Opened 12 years ago Closed 2 years ago

Parity. Chromium 25 maxes out at 60fps, Firefox Nightly manages 24fps.

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: bugs, Unassigned)

References

(
URL
)

Details

(Whiteboard: [js:t]) 

Pretty much just that. Demo is a lot more sluggish in Firefox.
Hmm.  This does look like jseng at first glance: lots of time in jitcode, lots of stub calls, CreateThis, etc.
I'm curious what IM does with this.
Blocks: WebJSPerf
Hrm. IM eh?
Welp. I have no idea if IonMonkey is enabled by default on the tinderbox ion builds (and asking in #js on moznet seems futile. no one spoke at all in the channel after I asked, for about a day - it is clearly an idling ghost town) so I have no idea if there is a secret javascript.options.*

but I grabbed the latest tinderbox anyway, and launched it on linux x86_64 machine over here.

IonMonkey ranged between 11-43 but usually seemed to hover around 20 fps.
Chromium 18 ranged between 35-63 but stayed pretty much rock solid at 61 fps (so, basically the 60fps cap).
FF Nightly ranged between 19-50 but was usually around 25 fps.

Obviously the values below fluctuated, but if anyone was curious...
FF Nightly CPU usage:
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
19784 nemo      20   0 1119m 266m  61m R   63  1.7   1:25.77 RunProcess                                                                     
 1477 root      20   0  495m 237m 203m R   55  1.5 330:52.49 Xorg 

Chromium 18:
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                        
20244 nemo      20   0 1288m 144m  30m S   49  0.9   0:15.45 chromium-browse                                                                
 1477 root      20   0  438m 178m 145m R   21  1.1 331:23.66 Xorg                                                                           
20268 nemo      20   0  396m  73m  46m S   13  0.5   0:03.99 chromium-browse 

Ion:
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                        
20437 nemo      20   0 1030m 299m  56m S   75  1.9   0:21.03 Main Thread                                                                    
 1477 root      20   0  498m 238m 204m R   30  1.5 331:40.09 Xorg    

Suggests to me that Chromium had wiggle room yet.

This is backed up I think by the fact that if I added 25 extra objects I got:
IonMonkey: 5fps
Chromium 18: 44fps
FF Nightly: 8fps
> asking in #js on moznet seems futile.

You want #jsapi.  ;)
Ah. Indeed.
11:20 < jandem> nemo: oh bug 769128 :(
11:20 < firebot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=769128 nor, --, ---, general, NEW, Ionmonkey default build doesn't use 
                 ionmonkey.

Sooo, ignore the supposed ionmonkey test above.
Although I guess the bit about nightly vs chromium for 25 objects is still interesting.
Ok. Well. That was a very simple patch, so I added the option to my about:config and reran it.
I'd rebooted in the interim and shut down various things, which might have helped a tiny amount w/ the ever-sucky fglrxi or overall system usage 'cause both nightly and ion ran a tiny bit faster.
Both Nightly and Ion averaged about 28fps I'd say. Ion's performance was unchanged whether I had started w/ the ion config var set to true or false.

With 25 extra objects, hard to say due to randomness of it, but there might have been a sliiiight improvement w/ the about:config ion option set to true. 13fps vs 10 fps.

Nightly managed roughly 18fps w/ 25 extra objects.

Chromium 18 also improved slightly. 47 fps w/ 25 extra objects and of course cranking along beautifully otherwise.

So. Assuming javascript.options.ion.content;true actually works as advertised, it doesn't seem to make much of a difference.

BTW, I tried FF10 pre-tracemonkey disabling, and it didn't make any difference.  ~25fps, ~14fps w/ 25 extra objects.

Anyway. Upshot. IonMonkey doesn't seem to help. At least not yet.
(In reply to nemo from comment #6)
> Anyway. Upshot. IonMonkey doesn't seem to help. At least not yet.

Thanks for the tests. This is a good bug--this is the kind of thing I want IM (and all our other work) ultimately to help. Hannes, does your visualizer run in the browser? I'm curious what it would show for this.

I see lots of js::mjit in the profile, so I suspect it's not running in IM. I think I also see about 10% of JS time being used to fiddle with types.
FWIW, after talking to kaelan about this, he told me the jit profiler was identifying hot spots of the form:
function foo(a,b) { if (a === undefined) a = 0; if (b === undefined) b = 0; /* do stuff */ }  in the box2D port.
http://code.google.com/p/box2dweb/

His guess, and it seems borne out by the code, is it was at least partly automated port.  There's more than a few nonsensical lines of code.

I'd try the emscripten box2d, but it is a bit different structurally, so it wasn't drop-in.

Soooo, I'm going through the code and replacing all these === undefined and seeing what it buys.

Maybe ¾s of the way through.  Will get back to you guys :)

Oh, IMO Firefox definitely needs to be smarter about those, and I'll probably file a bug on that too if you can't think of an already existing one.

Also, I tried a quick and dirty strip of those from the minified sources and, well, completely froze up Firefox. Like, unresponsive window at max CPU for 10 minutes at a time w/ no alerts to pause the script.  I'll probably file that too :)
Ok, Well. I tried replacing almost all those === undefined as per kaelan's advice.
And.  No faster really.
http://m8y.org/tmp/uglyhack.appspot.com/boingy/ - mirror of original
http://m8y.org/tmp/uglyhack.appspot.com/boingy3/ - reworked off of the unminified google code sources to try and drop almost all the if (var === undefined) var = 0 stuff
http://m8y.org/tmp/uglyhack.appspot.com/boingy4/ - google code sources - unminified and untouched, for profiling purposes


don't hit boingy2 unless you don't mind your browser possibly locking up - that was the one I tried to strip the === undefined from the minified version.  Clearly broken, and I'm just keeping it around because even broken it shouldn't kill firefox.
(In reply to David Mandelin [:dmandelin] from comment #7)
> (In reply to nemo from comment #6)
> Thanks for the tests. This is a good bug--this is the kind of thing I want
> IM (and all our other work) ultimately to help. Hannes, does your visualizer
> run in the browser? I'm curious what it would show for this.

I just tried it, after a lengthy wait to build the browser.
The graph shows: startup of browser, 10 seconds running boingy and closing of the browser.
Boingy starts running in the middle of the graph. Noticeable by the paths reported in the tooltip.

http://alasal.be/ionmonkey/boingy.html

Note 1: graph doesn't show anything standing out for me.
Note 2: the tracelogger can't yet see a transition from JM function to JM function. Important to know when looking to the graph. Hopefully I can add that in the future.
Note 3: Looks like I didn't have ionmonkey enabled. Not sure why. If needed I can search how to enable it and rerun it.
Hannes, probably bug #769128

try again w/ the pref?
Of course, I'm not too sure since adding it didn't seem to help anything for me.  But then, IM is far from finished and at least on AWFY isn't doing anything too break-out amazing yet.
Is there a downloadable version of the demo?  It refuses to load for me.
bhackett...

http://m8y.org/tmp/uglyhack.appspot.com/

boingy.zip is the mirror of the original site (using a minified box2d lib)
boingy4.zip is the same site, but with Box2D.js unminified and dropped in off the box2dweb google code project website.
Thanks.  After poking around with the JIT inspector a bit (plug: https://addons.mozilla.org/addon/jit-inspector/) and looking at the source, there are two main things here:

1. Most of the code is wrapped in '(function() { ... })();' blocks in global scope, which is something we should recognize as global rather than function code, which will improve the quality of type information and cut stub calls.  Fixing this locally doesn't seem to make much difference, as performance looks to be gated on #2

2. Almost all of the work seems to be done in the SolveVelocityConstraints function (makes sense).  This function has no loops, and is basically a ton of property reads/writes and floating point arithmetic on the values read out.  We don't have definite property information for any of these accesses, so they all go through a PIC.  I don't think recovering definite property info for the objects would be practical --- the objects seem to be allocated in a complex web of .call/.apply invokes and control flow, I guess to support plugging in new functionality.  The property accesses are on a small set of objects, though, and with a few shape guards GVN'ed up front the rest of the function could be compiled as if the accesses are definite properties.  This isn't possible to fix for JM, but is tailor made for IM.  The functionality to do this transform isn't in yet, but is filed as bug 771130.
Depends on: 771130
Whiteboard: [js:t]
I used the profiling stuff I've been working on and got some dumps of output:

http://pastebin.mozilla.org/1702923 (JM)
http://pastebin.mozilla.org/1702930 (IM)

The profiling works with operation callbacks, so the line numbers aren't exact, but it looks like in JM we're spending ~83% time in JS + GC, and IM has ~89%. 

These don't fully agree with SolveVelocityConstraints being the hottest function, so the results could possibly be skewed. I also tried this with the SPS profiler for JM as well, and I was getting similar 'total' times but was having trouble decoding the 'self' output. Also with SPS, the frame rate plummets by sheer fact of profiling. Profiling with the Profiler API object didn't appear to affect performance much at all (if any).

I also upped the sample rate to get 10x more samples, and got pretty much the same profile.

Also, here's a call graph: http://people.mozilla.org/~acrichton/out.pdf where big nodes correspond to large "self" times and the edge percentages are what percentage of the time the edge is taken from the previous node.
So. Was marked as depends on bug 771130  but that was fixed a while ago, and performance in latest nightlies seems to be as sucky as ever.
Well. Maybe a bit improved, but still pretty sucky.
Summary: Parity. Chromium 18 maxes out at 60fps, Firefox Nightly manages 24fps. → Parity. Chromium 25 maxes out at 60fps, Firefox Nightly manages 24fps.
For me, Firefox runs almost at the same speed as Chrome.
(In reply to Guilherme Lima from comment #17)
> For me, Firefox runs almost at the same speed as Chrome.

I think I tried it recently (last week) and still having a bad performance on nightly, compard to v8. Can you give the fps numbers and the builds you tested?
I'm using Nightly (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20130521 Firefox/24.0)

It starts slow (8~12fps), then speeds up 30~40 fps. Then it keeps oscillating between 45 and 35 fps (it goes down to 35 when the doll falls and hits the ground). Then when it's on the floor, it oscillates between 56~60fps.
Hm. Trying in latest nightly here, on 64 bit linux with layers acceleration force-enabled, it is indeed quite fast.  55-59fps once dummy settles down.  Without layers accel it is unsurprisingly dog-slow. 12-13fps.

With layers accel in nightly, I spawned 30 extra objects (clicking w/ mouse at top of screen above dummy) and got a frame rate that was still about mid-50s in Nightly once things settled down, and ~30fps while the objects were raining down.

Tried in Firefox Stable, 55fps or so for just dummy lying on floor after fall, ~9fps for 30 objects falling, ~20fps after 30 objects settled down.

When I tried the same in Chromium 25 I got an almost rock solid 60fps for dummy lying on the ground, ~30fps as objects fell, and an almost rock-solid 60fps once they settled down.

This is obviously a bit approximate based on object dimensions and where they happened to fall and how rapidly I clicked spawn.  But, seemed fairly repeatable

Sooo, fixed I guess with Nightly almost at parity with Chromium 25.  Well, that's unless later versions of Chromium which I don't have do even better - getting nightlies of Chromium is annoyingly convoluted these days.  Not sure what happened to the buildbot.

Linux users I suppose still won't get the same benefit if they have layers accel disabled by default.
On subject of layers accel default.
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV730XT [Radeon HD 4670] (prog-if 00 [VGA controller])
[    26.043] (II) Module radeon: vendor="X.Org Foundation"
[    26.043]    compiled for 1.13.0, module version = 6.99.99
[    26.043]    Module class: X.Org Video Driver
[    26.043]    ABI class: X.Org Video Driver, version 13.0
Is this still a script engine bug when the layers acceleration is dominant?
Well, sure, I'd call it basically fixed, given nightly w/ layers accel is almost at parity w/ chromium 25.
No idea *what* fixed it, but, maybe just ion+bc ?
Assignee: general → nobody

URL doesnt work anymore

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.