| The roads I take... | Weekly Status Report, W34/2008 >>

KaiRo.at Mandelbrot Going Public

As comments to yesterday's post about TraceMonkey suggested I should show my code so the JIT code could be improved for things like what I'm doing, I decided to go all the way and publish this today.
I just completed putting all my code of this project under the Mozilla tri-license and making it available via both a gitweb interface and for cloning with git clone http://git-public.kairo.at/mandelbrot.git.

That said, a few details about the application itself:

This is a fun side project, its main target is for me to learn XULRunner and improve my skills with the used technologies. Its second target is to recreate an application I had started for my my final paper in school with modern technologies.
The application renders images of the Mandelbrot set fractal, the original application had nice zoom functionality and could even render the very similarly calculated family of Julia set fractals, which are both features I want to add incrementally to this XULRunner-based version as well.

The current versions calls itself "KaiRo.at Mandelbrot 4pre", which probably warrants a short view on the version history: The first version, "RK-Mandelbrot 1.0" was created in Visual Basic 3 during work on that school paper, I incremented the minor version number as I went along with that work, the version I had on a disk coming with the paper was "RK-Mandelbrot 2.0", this or a slight minor update to it was also used during the presentation/exam on that paper. I later updated it to Visual Basic 5 and played with a few features, calling the result "KaiRo-Mandelbrot 3.0", also noting the change from using my initials to the "KaiRo" name for my work. Because of this history, I'm targeting a version number of 4.0 for the XULRunner rewrite, and also using "KaiRo.at" as the vendor name, as that's also what I'm using as my corporation name prefix.

Some comments on the current code:

On the base level, I created a mandelbrot launch script, which tires to find a XULRunner in a few places and uses it to launch the app using the application.ini inside the xulapp directory, which contains files in the usual structure for XULRunner apps.

In the running app (the launch script also launches the error console for debugging), the File menu enables access to drawing the image, saving it (very ugly right now, hardcoding /home/robert/temp/canvas-save.png as the path!) and quitting the app. The Settings enables different settings for maximum number of iterations (I'm using a simple escape time algorithm) and color palettes (which are currently stretched according to the max iterations number; also, I have not ported all palettes I had in the VB version, leaving the non-ported ones in an ugly comment in the JS file). Today, I also added a Debug menu that allows switching TraceMonkey on and off and switching between the slow but nice-looking object-oriented algorithm and the faster but not so pretty numeric algorithm. I also added a label at the bottom of the window that informs about the currently performed action and a rough time measurement when drawing is complete.

The image you'll get with the default settings of max. 500 iterations and my custom "KaiRo.at" color palette looks like this:
Image No. 20151
Once I can do a zoom function, I hope I can produce more interesting images - I'll publish a number of them in the gallery.

There's a lot that probably can be improved in that app, it's just a fun personal playground, as I said. But if anyone wants to look into what it does and perhaps see how TraceMonkey could perform better on it, feel free to look into it, the source is all open!

Beitrag geschrieben von KaiRo und gepostet am 23. August 2008 19:39 | Tags: Mandelbrot, Mozilla, XULRunner | 6 Kommentare

TrackBack/Pingback

  • Home of KaiRo: Linuxwochen, Mandelbrot-Demo, MozCamp Wien (Pingback)
  • Kommentare

    AutorBeitrag

    prefiks

    zitieren
    You get quite nice speedup if you call drawPoint directly (not from setTimeout).
    Also drawing pixel by pixel has a bit of overhead, if you comment last two lines in drawPoint you get nice 8x speedup with JIT.
    23.08.2008 21:06

    KaiRo

    Webmaster

    zitieren
    Not using setTimeout mean I'll never be able to make UI responsible while drawing - even though that doesn't work well even now, it's something I'd like to achieve.
    Oh, and commenting out those two lines does mean not painting the image at all. Nice if that help performance, but the whole point of this application is to actually draw those images. Maybe it points to canvas having some possibilities of being sped up as well though.
    25.08.2008 01:12

    Boris

    zitieren
    Thoughts on the performance bottlenecks here
    I haven't profiled this, so take what I say with a bit of a grain of salt. I'm basing a lot of these comments on my own experience a week or so ago with writing a mandelbrot program in JS:

    1) You're doing a timeout for each point. While this does keep the UI responsive, it introduces a good bit of overhead.

    2) You're doing a separate fillStyle set for each point. This is actually surprisingly expensive, since it involves parsing the color string, calls into cairo, etc. I know that my code got a quite significant speedup when I batched up all the points of one color (or rather I batched up all the points, binned by color) and drew them all after doing a single fillStyle set. If you can do any sort of batching here, even if it's not global over the whole algorithm, it would likely help.

    3) You're drawing each point as a separate rect. I discovered that I got a 2x speedup or so when I batched up adjacent points of identical color and drew a single bigger rect to cover them all. Your algorithm is going down vertical strips just like mine was, so I suspect you could get a similar speedup.

    None of the things above are time spent in the JS engine, by the way, so none of them would be helped by the jit.

    Given that, I'm pretty impressed that you got a 30% speedup from the jit on the non-object case. I suspect that might be all the win you'll see from the jit on that case, but I could be wrong.

    I'll try to do some digging to see what's going on with the object-oriented case.
    26.08.2008 04:21

    prefiks

    zitieren
    You can grab patch with some speedups from http://prefiks.org/k/1.diff .

    Zuletzt bearbeitet von KaiRo am 12.09.2008 00:17

    26.08.2008 15:02

    Boris

    zitieren
    More data
    So the first issue is that the JIT currently doesn't handle heavyweight functions, and in the object-oriented example the square/dist/add functions are heavyweight because they refer to the outer "complex". I filed bug 452498 on this.

    I tried changing that code to look like this:

    var complex_ops = {
    square : function() {
    return new complex(this.r * this.r - this.i * this.i,
    2 * this.r * this.i);
    },
    dist : function() {
    return Math.sqrt(this.r * this.r + this.i * this.i);
    },
    add : function(aComplex) {
    return new complex(this.r + aComplex.r, this.i + aComplex.i);
    }
    };

    function complex(aReal, aImag) {
    this.r = aReal;
    this.i = aImag;
    }
    complex.prototype = complex_ops;

    and that sped up things, but it also sped up the non-jitted version. It really doesn't make sense to me that this doesn't win out with the jit. I've filed bug 452499 on it.
    27.08.2008 23:24

    KaiRo

    Webmaster

    zitieren
    Boris:
    Thanks for the tips and the bug reports, esp. the latter was what I hoped for when I opened that code! :)

    prefiks:
    Thanks for your patch, this looks quite nice, I guess I'll just incorporate this as-is into my app!
    31.08.2008 03:07

    || Kommentar hinzufügen