Google does fractals in HTML5 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 …
Firefox blew chunks before finishing and was realllly slow. Safari finished and was fast. The ol' standard if-it-won't-work-in-firefox-it'll-work-in-safari adage holds true.
So why am I using (a Safari skinned) Firefox rather than Safari? I swap between them once one pisses me off sufficiently enough to make the switch (bookmarks and all that nonsense). Firefox is almost at that point.....
Alright, I might be ancient, but why does the IT world have to keep re-inventing ways of doing things and making them slower. There'll now be a whole generation of youngsters growing up thinking that Javascript is the way to do high speed calculations. What Boll***s.
>and uses the Web Workers API, which allows for the JavaScript processing to spawn multiple and parallel rendering calculations to speed up the painting of each fractal image. The Web Workers API can also spread the rendering work over multiple cores and threads in a machine.
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:
"Modern browsers have optimized JavaScript execution up to the point where it is now possible to render in a browser fractals like Julia sets almost instantly."
and so pushing browsers as a suitable platform for heavy duty work is doing the world a massive disservice. For the sake of your office's and data centre's electricity bill and equipment inventory, plan on avoiding web stuff like Ruby, Javascript, PHP etc. Twitter had to abandon Ruby for the slightly better SCALA, and Facebook had to invent a PHP compiler just to stay alive in the face of expansion costs. Continued expansion will put huge pressure on those stop gap measures in due course.
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.
Javascript, being generally a client side language, just pushes the costs out to the clients, and that's their electricity bill. But it is also probably their battery these days. There are real benefits to be had on the client side to having a properly written natively compiled app that makes the absolute best use of the CPU. Battery technology is not making useful advances any more, and the abundance of smart portable devices makes the issue more important. Better to have a native app that downloads minimal data from a server than having to download the app, JIT compile it, and get the data too. Imagine a Javascript word processor; the javascript code is likely to take far longer to download over the client's expensive 3G link than the actual document they want to edit.
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.
So there's no point to this and it would be faster using a proper language and compiler. So what? I used to write a mandlebrot generating program in every new language I learned just to prove I could do it and see how the speed compared to the other languages I knew. My first was on the Sinclair ZX Spectrum in monochrome and it took 11 hours to run so a modern compiler may be quicker than JavaScript but it still seems pretty quick to me.
I tried it in Firefox 3.6.13 and found it to be practically unusable. Occasionally reporting 2million flops/second max.
I tried it in Firefox 4.0b11pre (aka Minefield, about 12 days out of date, update downloading as I type) and found it to be awesomely fast. It regularly reported over 100million flops/second, with a max of 368million that I observed.
It's a lovely advert for how much faster Firefox 4 is going to be.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
