460964 - TM: No speedup (instead major slowdown) on JS+canvas raytracer

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Boris Zbarsky [:bzbarsky]]

The testcase in the URL doesn't speed up much with jit.  It's basically doing a bunch of computations, sticking them into the imagedata array, and then once per frame hitting the canvas.  All the natives it uses (sin, cos, sqrt) are traceable.

Attached is a JS shell version of the code (computes the array for one frame).  This gets a 10% speedup in opt JS shell, and a 30% slowdown with debug JS shell.  Debug stats:

  recorder: started(175), aborted(68), completed(172), different header(48),
            trees trashed(29), slot promoted(27), unstable loop variable(63),
            breaks(9), returns(1)
  monitor: triggered(16728), exits(16056), type mismatch(669),
           global mismatch(3)

I did do a verbose log, but it's the usual glorious tens of megabytes.  Here's the output of "grep 'Abort' ~/log.txt | sort | uniq -c | sort -n -r":

  14 Abort recording (line 65, pc 94): Loop edge does not return to header.
  12 Abort recording (line 142, pc 46): Loop edge does not return to header.
  10 Abort recording (line 106, pc 113): Loop edge does not return to header.
   9 Abort recording (line 45, pc 161): Inner tree is trying to grow, abort
                                        outer recording.
   7 Abort recording (line 164, pc 435): Loop edge does not return to header.
   5 Abort recording (line 65, pc 100): Inner tree is trying to grow, abort
                                        outer recording.
   3 Abort recording (line 224, pc 585): Loop edge does not return to header.
   3 Abort recording (line 164, pc 435): Couldn't call inner tree.
   2 Abort recording (line 156, pc 190): Loop edge does not return to header.
   1 Abort recording (line 65, pc 94): Couldn't call inner tree.
   1 Abort recording (line 164, pc 441): Inner tree is trying to grow, abort
                                         outer recording.
   1 Abort recording (line 146, pc 114): Inner tree is trying to grow, abort
                                         outer recording.

Oh, I'm using a pull from this morning, so the thin loops stuff is in this.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: The testcase

Comment 2

[Arpad Borsos [:Swatinem]]

I've recently found this: http://lucille.atso-net.jp/blog/?p=642 An ambient occlusion renderer in Javascript. May be a good source for benchmarks as well.

Comment 3

[Boris Zbarsky [:bzbarsky]]

That should probably get a separate bug, since it's fundamentally a quite different testcase (for example, is uses canvas in a totally boneheaded way, and inside some of the loops, so that some of the code isn't even traced).  What a profile mostly shows is that (1) we're spending a lot of time off trace and (2) we're spending a lot of time allocating/deallocating stuff (not surprising for new-object-happy code like this).

Comment 5

[Boris Zbarsky [:bzbarsky]]

Probably also related are http://mark.webster.googlepages.com/jsrt-pretty.html and http://mark.webster.googlepages.com/jsrt.html

We should retest those once we have a handle on the animation issue.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Bug 460858 points out that not only do we have no win here, we have an up to 10x performance loss over jit disabled.  That sounds bad.

Comment 7

[Andreas Gal :gal]

Did you test this with TM or with mc?

Comment 8

[Boris Zbarsky [:bzbarsky]]

I tested with TM as of when I filed.  Bug 460858 presumably tested with mc as of then.  Could retest, I guess.

Comment 9

[Reece H. Dunn]

I have retried http://mark.webster.googlepages.com/jsrt.html (setting the javascript.options.jit.content and chrome to true). Now, it gets to 44% taking a long time and then produces a "this is a slow javascript" dialog.

Trying the http://mark.webster.googlepages.com/jsrt-anim.html page, I get the rendering hovering around 150fps or 170fps with a normal range of 140-190fps. This can go upto 280/320fps, and as low as 80fps, but only hits those rates briefly.

Mozilla/5.0 (Windows; Security; Windows NT 5.1; Locale; rv:1.9.1b2pre) Gecko/20081022 Extra.Firefox

Comment 10

[Boris Zbarsky [:bzbarsky]]

With today's tracemonkey JS shell on the testcase posted above I see a 10% speedup in the opt shell with jit and a 130% slowdown (takes 2.3 times as long) in the debug shell with jit.  Jitstats are:

recorder: started(704), aborted(354), completed(318), different header(7), trees trashed(1), slot promoted(0), unstable loop variable(331), breaks(24), returns(7), unstableInnerCalls(48)
monitor: triggered(13295), exits(13295), type mismatch(0), global mismatch(1)

But that testcase is only one frame; on the web-based testcase the slowdown kicks in more and more as we go through more frames.  I suppose I can try to create a testcase that will run multiple frames; let me do that.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase that runs 40 frames in a row

This doesn't show the slowdown (and in fact, shows us with a 5x speedup for a number of the frames there, in an opt shell).

I'll see what current tracemonkey optimized browser does.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Note that there is canvas access between the frames in the original testcase, so that might also be causing us issues...

Comment 13

[Boris Zbarsky [:bzbarsky]]

OK, using an opt tracemonkey firefox on the jsrt-anim page I see most frames taking somewhere in the 50ms range, with some as low as 10 and some shooting up to 100+ (rarely).

On the jsrt.html page, I get pretty inconsistent results.  Sometimes it works in 300ms or so.  Sometimes it's closer to 2800ms.  A few times I got the slow script dialog (so it took over 10 seconds).  no jit consistently gets about 3500ms.

So sounds like the bug as filed is more or less resolved (certainly what I saw when I filed is gone in browser, since after the first frame we get a nice speedup), but we still have a regression problem on <http://mark.webster.googlepages.com/jsrt.html>.  Andreas, do you want to morph this bug, or should I file a new one?

Comment 14

[Boris Zbarsky [:bzbarsky]]

Oh, and we definitely have a 4x slowdown with jit on <http://mark.webster.googlepages.com/jsrt-pretty.html>.  Again, we might want a separate bug, with separate testcase.  Let me know.

Comment 15

[Brendan Eich [:brendan]]

Could morph, but if we can id the change, or if the bug is overlong, and in any event when a patch lands that stays in the tree -- new bug is best.

/be

Comment 16

[Boris Zbarsky [:bzbarsky]]

OK.  Filed bug 463478 on the 4x jsrt-pretty slowdown.
Filed bug 463487 on the 20x jsrt slowdown if gc is allowed.
Filed bug 463490 on a fatal multitrees assert jsrt hits.

This bug can probably be marked worksforme, but it'd be awful nice to have a regression test for this somehow...