HTML 5 Canvas: Linux Performance Issues
Will Daniels
I started playing with HTML 5 canvas the other day, rendering
fractals, and I noticed an enormous (2000%) disparity in performance
between Ubuntu Linux and Windows builds of Firefox 3.5.3 (see
http://willdaniels.co.uk/blog/14-math-stuff/28-playing-with-fractals-in-html5).
After testing a number of different browsers on different platforms, I
concluded that: Opera is consistently slow, Chromium is consistently
"swift", and Intel/PGO builds of Firefox are consistently fastest.
I'd really like to help improve performance of GCC builds of Firefox,
but I don't (yet) know anything about whether the PGO capabilities of
GCC are used in building the Ubuntu Firefox package, or indeed whether
it is PGO primarily that is making the difference here (i.e. perhaps
the Intel compiler is just that much better at optimising this
particular arithmetic case).
So I thought this might be the best place to ask for pointers to help
me figure all this out, and that perhaps you might otherwise be
interested in this example as a clear demonstration of the immense
performance impact the compiler can have on occasion.
One thing in particular I'd like to ask here, is whether you keep any
3.5.3 Linux binaries that are compiled with the Intel compiler without
the PGO phase, for comparison?
Any information on this subject gratefully received! :)
Cheers,
Will
PS: If anybody can suggest also why the rendering of my fractal "zoom
box" (on the mousemove event) is noticeably lagged using the Mozilla
Linux build, but not the Ubuntu build (or any other build of any other
browser on any other platform that I tried) I would appreciate that
also :P It's very odd because it is only using getImageData and
putImageData the same as the much improved rendering of the main
fractal image, yet I can't think what else might influence the
responsiveness of the mousemove event :S
Boris Zbarsky
> After testing a number of different browsers on different platforms, I
> concluded that: Opera is consistently slow, Chromium is consistently
> "swift", and Intel/PGO builds of Firefox are consistently fastest.
Just as a note: none of the Mozilla.org builds are done with icc. The
Windows builds (which use PGO) are done with MSVC. Last I checked, icc
porting work was sporadically happening, but not done.
> I'd really like to help improve performance of GCC builds of Firefox,
> but I don't (yet) know anything about whether the PGO capabilities of
> GCC are used in building the Ubuntu Firefox package
Almost certainly not; GCC with PGO enabled ends up with internal errors
in its profiling information bookkeeping if you try to use it on
Firefox. As in, the PGO is just too buggy to use so far.
The Linux builds mozilla.org ships are not using GCC's PGO either.
> or indeed whether it is PGO primarily that is making the difference here (i.e. perhaps
> the Intel compiler is just that much better at optimising this
> particular arithmetic case).
Just to check... were the Ubuntu builds 64-bit, by any chance? If so
(and this is my most likely hypothesis at the moment), you're probably
seeing the lack of a 64-bit jit in Firefox 3.5.3's JS engine. The
mozilla.org builds are 32-bit.
> One thing in particular I'd like to ask here, is whether you keep any
> 3.5.3 Linux binaries that are compiled with the Intel compiler without
> the PGO phase, for comparison?
As I said above, I don't think it's even possible to build Firefox with
icc at the moment. I could be wrong about that, though!
> PS: If anybody can suggest also why the rendering of my fractal "zoom
> box" (on the mousemove event) is noticeably lagged using the Mozilla
> Linux build, but not the Ubuntu build (or any other build of any other
> browser on any other platform that I tried)
_That_ is really odd. I'll look into that.
-Boris
Will Daniels
On Oct 8, 3:17 am, Boris Zbarsky <bzbar...@mit.edu> wrote:
> Just as a note: none of the Mozilla.org builds are done with icc. The
> Windows builds (which use PGO) are done with MSVC.
LOL, OK, not sure where I gathered that misconception from then,
though I guess it's not substantively important anyway, especially in
view of:
> Just to check... were the Ubuntu builds 64-bit, by any chance? If so
> (and this is my most likely hypothesis at the moment), you're probably
> seeing the lack of a 64-bit jit in Firefox 3.5.3's JS engine. The
> mozilla.org builds are 32-bit.
Aha, yes that makes a _lot_ more sense than putting it down to PGO! I
am indeed using the 64-bit Ubuntu binaries (though it came as some
surprise when I checked - obviously I'm not booting from the root
partition that I thought I was :D). In any case, I was not aware that
there's no/limited JS JIT on 64-bit, so I guess that explains it well
enough, given the degree of floating-point arithmetic involved.
> > PS: If anybody can suggest also why the rendering of my fractal "zoom
> > box" (on the mousemove event) is noticeably lagged using the Mozilla
> > Linux build, but not the Ubuntu build (or any other build of any other
> > browser on any other platform that I tried)
>
> _That_ is really odd. I'll look into that.
>
> -Boris
That would be cool, though to be honest I haven't really looked at it
properly myself yet, and no doubt you have bigger fish to fry ;) I
would be embarrassed if it turned out to be just my lousy javascript
knowledge. Though on second thoughts, it does work fine in all other
cases...so I don't know...maybe if someone could just confirm for me
that it *is* lagged with the standard Mozilla builds for Linux, in
case I did something wacky with the install?
Cheers!
Will
Boris Zbarsky
> That would be cool, though to be honest I haven't really looked at it
> properly myself yet, and no doubt you have bigger fish to fry ;) I
> would be embarrassed if it turned out to be just my lousy javascript
> knowledge. Though on second thoughts, it does work fine in all other
> cases...so I don't know...maybe if someone could just confirm for me
> that it *is* lagged with the standard Mozilla builds for Linux, in
> case I did something wacky with the install?
I can certainly confirm that, in my Linux VM. No lag on the small
mandelbrot, but quite noticeable lag on the big one. No visible lag on
either one on the host OS (Mac).
I hadn't gotten past confirming yet, but _something_ is going on there.
My guess is painting, though that doesn't explain why you don't see it
in the Ubuntu builds....
I believe 64-bit jit will happen in Firefox whatever-is-after-3.6.
-Boris
Will Daniels
> On 10/8/09 3:40 PM, Will Daniels wrote:
>
> > That would be cool, though to be honest I haven't really looked at it
> > properly myself yet, and no doubt you have bigger fish to fry ;) I
> > would be embarrassed if it turned out to be just my lousy javascript
> > knowledge. Though on second thoughts, it does work fine in all other
> > cases...so I don't know...maybe if someone could just confirm for me
> > that it *is* lagged with the standard Mozilla builds for Linux, in
> > case I did something wacky with the install?
>
> I can certainly confirm that, in my Linux VM. No lag on the small
> mandelbrot, but quite noticeable lag on the big one.
That _really_ is odd, since the zoom box itself is actually the same
size in both! I wonder if there is some delay then on the getImageData
relative to the size of the source context perhaps? I have to do some
more tests, though I don't think that can happen until the weekend
now...no reason to hurry anyway I guess.
> I believe 64-bit jit will happen in Firefox whatever-is-after-3.6.
Nice :) If there's anything I can do to help there, please let me
know. I'm not at all familiar with the Firefox architecture or code,
but I'm a capable programmer, a fair mathematician and a very fast
learner :P
Perhaps there are some relatively isolated areas of the JIT code that
I could get a sufficient handle on quickly to help with? Otherwise, I
don't mind just doing a bit of testing or something - I'd like to do
my bit to make sure Firefox's Linux performance is as good as it can
be.
Thanks again for your assistance here,
Will
Boris Zbarsky
> That _really_ is odd, since the zoom box itself is actually the same
> size in both! I wonder if there is some delay then on the
> getImageData relative to the size of the source context perhaps?
Yes, there is. getImageData on Linux apparently has to copy the image
from the X server (and hence possibly from the graphics card) back to
Firefox (an RAM). This tends to be slow...
Sorry for the lag here, but I only recently figured out what's going on
with this.
> Perhaps there are some relatively isolated areas of the JIT code
> that I could get a sufficient handle on quickly to help with?
There might well be, but I'm not an expert on that. Drop by the #jsapi
channel on irc.mozilla.org and ask around?
-Boris
Boris Zbarsky
> So the only case where rendering to image-contexts would hurt, is
> probably working with large images and transformations.
For what it's worth, I'm pretty sure there's a bug covering this Linux
getImageData issue.
-Boris