Google does fractals in HTML5
Take a break with Julia and Mandelbrot
Fractals. They're porn for techies. Well, truth be told, porn is porn for techies. But fractals aren't far behind.
Fractals are far more interesting, at least in the long run. And you can look at fractals at the office without worrying if the boss will walk by.
If you're a techie, it's time you visited Google Labs project that uses the browser to render fractal images describing various Julia and Mandelbrot sets.
According to a blog post from Google software engineer Daniel Wolf, the fractal renderer is coded in HTML5 using the Google Maps API to allow you to zoom in and out on a fractal image and pan around the image as well.
The images in this story were rendered on a single-socket workstation with a 2.27 GHz Xeon E5507 processor, 6 GB of memory, and an AMD FirePro V4800 graphics card. This machine is rated at a 7.0 on the Windows experience index, and it is running Windows 7 Professional 64-Bit and Google Chrome 9.0.597.84. As best as I can figure, the Google browser fractal generator is not using OpenGL and doing calculations on that graphics card. It didn't matter. They rendered in about a second.
And once again, raise a coffee mug to Benoit Mandelbrot, who used computers to render fractal images and popularized them and who died back in October.
Now get back to work. ®
Been there, done that
I once coded the Mandelbrot algorithm in Postscript. I wasn't very popular when I hogged the department's Laserwriter for over 24 hours just to print one page!
Woo-fu****g-hoo. This is a perfect example of how laziness breeds complexity and inefficiency. Fractal generation generally consists of one for loop executed inside another, covering each pixel on the screen, with no inter-iteration dependency. Yes, you can separate them out over different cores for speed using Web Workers, but why bother? Do a bit of reading and discover decent C/C++ compilers like the ones from Intel and Sun (maybe even GCC these days). These will both spot such loops for you and do the same thing with threads at run time without you ever having to think about it in your coding. And it will probably run significantly quicker as well. And that's before you start contemplating bending it to fit on a GPU.
Okay, so this is just an eye candy demo of no major consequence. But to say:
The only benefits of Ruby, PHP, and other such languages is that they provide rapid development enabling a service to be brought to market quicker. The labour costs are cheap too. That is an important commercial consideration. But if your service expands and your electricity and inventory bills start heading in to the millions (or billions if you've been very successful indeed), the costs of that initial laziness start looking very high indeed.
Of course many web traditionalists point to their great saviour, the JIT compiler. Sure, a JIT compiler does produce executable object code which runs modestly quickly. But CPUs are complicated beasts these days with pipelines, caches, etc. I'd put good money on most JIT compiler's object code not being as fast as that produced by, for example, Intel's native compiler. Intel build the chips. The writers of TraceMonkey, V8, etc. didn't. If your JIT compiler is 5% less efficient than a natively written app, for a really big data centre that could amount to millions in electricity and inventory bills a year, every year . You have to wonder how much properly written native application code you could get written for that much money.
You don't get it, do you, it's a proof of concept of the technology. No one *needs* a Mandelbrot set program, so it might as well be written in HTML5 as anything else. It's the graphical equivalent of a "Hello, world!" program.