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
<< How Fast Is TraceMonkey In Real World? | The roads I take... | Integration eines Magento-2-Webshops mit FreeFinance und selbstgebautem Warenmanagement >>
git clone http://git-public.kairo.at/mandelbrot.git
.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.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.Beitrag geschrieben von KaiRo und gepostet am 23. August 2008 19:39 | Tags: Mandelbrot, Mozilla, XULRunner | 6 Kommentare
TrackBack/Pingback
Kommentare
Autor | Beitrag |
---|---|
prefiks | |
Webmaster | 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 | 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 | 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 | 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 |
Webmaster |