<< Weekly Status Report, W33/2008 | The roads I take... | KaiRo.at Mandelbrot Going Public >>
How Fast Is TraceMonkey In Real World?
What I wondered is how fast it is in code that is no benchmark but stuff a real application might use. And as I have my "Mandelbrot" fun project as a XULRunner app (see the last paragraph of recent status update post), which naturally does a lot of looping over the same equation, so I thought it might be a good candidate for optimization.
So I fired up the XULRunner app, doing four testruns of "time mandelbrot" (launching a script that runs my XULRunner build from today's trunk code under primitive unix time measuring) and looked at the amount of user and sys time used. I didn't want professional benchmarks, I wanted just a rough estimate of real world numbers, so it was OK that I needed to manually click the "Draw Image" button and manually click "File > Quit" once the CPU usage came down from fully using one core. I only wanted rough numbers to see if there's a visible difference, so I could live with those deficiencies and rounded the average of two runs roughly.
For the unoptimized, heavily JS-object-based approach I already had last week, I got a number that was about the same as I estimated previously - about 96 +/- 2 seconds. When I turned on the
But even though
Z = Z.square().add(aC);looks good for the
Z = Z² + Cequation, it's not that efficient to do two JS object creations for every iteration, so earlier in the week, I replaced that nice code with pure math and simple variables only. That helped performance a lot and saved about 90% of the time, cutting it down to about 9.4 +/- a half seconds.
Having that code activated, I turned on TraceMonkey once again. And now, it really helped: 7 +/- 0.2 seconds! That's about 30% faster!
For already optimized, pure JS math code (which is probably more real-world than nice-looking object stacking), squeezing even 30% more performance out of this calculation is surely nice!
Still, running my old Visual Basic 5 application under Wine has, apart from more features, two advantages to this XULRunner app: For one, it updates the image frame in the UI during calculation and not only at the end of execution, which is better felt performance as you see what it's doing. For the other, it's still 20% faster, using about 5.6 +/- 0.2 seconds with the same instrumentation - and that though people say VB is so slow. Bummer.
So, good work done, TraceMonkey friends. But there's still more potential to use the CPU more efficiently. Keep on the good work!
- buzz: Home of KaiRo: How Fast Is TraceMonkey In Real World? (TrackBack)
- Recent Faves Tagged With "optimized" : MyNetFaves (Pingback)
- Paper mario walk through - Through ultimate - Walk-through (Pingback)
If you have something that doesn't speed up, file a bug. Tracing promises to eliminate unnecessary object wrappers for complex number pairs, some day.
Even your 30%-improved code would be good to see, so we can make sure it's not aborting on something that should be handled, but isn't. If you have a debug build, setenv TRACEMONKEY verbose and grep -i abort on the stdout.
What Brendan said. My own mandelbrot thingie so far has picked up a factor-of-3 win from tracemonkey, but I had to fix some things along the way to keep it from falling off the trace (things fixed in Gecko, not in the mandelbrot script). So if there's a case when there is no speedup, that just means that there's something you're doing the jit doesn't handle yet, and you're getting the pure-interpreted version, as usual. It would be good to know what this something is so the jit can be fixed.
I haven't filed a bug yet, as I'm not completely sure on what to file it - but the code that gets the 30% improvement is here: mandelbrot.js:122 now that my source is open. The code that doesn't see optimization is in the function right above that, but of course using the complex() object definition I have in the same file.
Last edited by KaiRo at 2008-08-23 20:00
I have made some test on our open source CMS systems GUI. Unfortunately swithing on tracemonkey does not make the app 30% faster, but it can be felt. We need to do more measurements. But Firefox 3.1 is so far much better that IE8, both is speed and compatibility.