Intel/Mozilla's River Trail (Javascript ParallelArray)

[opinali]

Just to muddle the waters even further:
http://www.youtube.com/watch?v=jueg6zB5XaM
http://www.theregister.co.uk/2011/09/17/intel_parallel_javascript

This is a relatively modest and incremental change to JS (if compared to Dart, NaCl or plugins like Java/Flash/Silverlight/etc.); they just added a ParallelArray object that allows numerical computations to take advantage of multiple CPU cores and SIMD instructions. Prety smart and obvious extension of WebGL's typed arrays.

Mozilla is fully backing this, which seems fair since Intel is walking the standards way, proposing the feature to ECMA. You can notice in the YouTube video that the browser used in the demo is Firefox, so I guess Intel implemented this on top of Mozilla's latest JS VM. Hopefully the feature is uncontroversial enough to be quickly agreed upon by all browser makers, this should be a no-brainer(*), and Intel certainly knows its stuff here so the design should be very good.

((*) Notice that IE10 will support typed arrays, even though MS won't support the rest of WebGL...)

But we can also see why this won't still be good enough for Javascript lovers to claim that other alternatives are not necessary: when I started watching the demo video, initially showing the animation running at 40-50 fps, I thought "OK now they will switch to the parallel version and make this run at 600 fps, like the Reg article promised (15X speedup)". BUT the animation was already in parallel mode... then they disable it, and it drops to a miserable 4 fps!

That's your best, Javascript? Maxing out EIGHT FREAKING CPU CORES (supposedly 16 hardware threads) - in a machine that I'm sure, should be a bleeding edge i7 box - to offer 40fps, in a simple 4,000-particle graphics demo that would easily run ten times faster than this, with a SINGLE core, in C (maybe even in Java)? If somebody knows more detail of the demo please clarify - for one thing, even the serial version benefits from Mozilla's typed arrays; Firefox was pioneer implementing this and they still lead benchmarks that benefit from it - but maybe the ParallelArray stuff was only prototyped in interpreted mode? Or maybe there's too much per-particle maths so the performance is fair (I've read the code briefly but this 3D geometry math is not really my field)? That doesn't seem plausible either, because the behavior of the particle system doesn't look too advanced, in fact it's a pretty common animation - a "fish swarm" pattern that I've seen a million times since the old times of the Assembly demoscene (and yeah I feel old to remember that). The background is crude, the particles are tiny images, there's no significant 3D geometry anywhere except the particles' trajectories.

Back to the standards discussion, once again I'm a Firefox user and sometimes a Mozilla fanboi, but doesn't this introduction of River Trail make Mozilla's severe criticism of other alternatives look a bit odd?  I for one, had never heard of this Intel project before; and I'm sure Mozilla collaborated with its initial, closed-doors development.  They are submitting it to ECMA, but ONLY after they already have the initial design AND implementation complete... as part of a major in-browser, production-quality Javascript VM no less. No involvement of competing vendors, or standards groups, since the napkin-sketch phase (which is what open standards pundits require from everybody else).  Well, how is this any different from (for example) Google doing all the design and initial impl of Dart behind closed doors and in secrecy, and only starting to opening it up after they can show some first alpha-quality release. The major difference is the scale of each project - River Trail is a single-class library, Dart is a full-blown programming language and VM/runtime; so it's reasonable if the later needs much more time in each stage (I guess Google will initially publish the project with an open source license, but I wouldn't count on a submission to formal standardization before a couple years at best).

Yeah, another important difference is that River Trail is an incremental extension of existing (Javascript) or proposed (WebGL) web standards; while Dart is a more radical alternative that competes with the status quo instead of complementing it. This means that you can only be a nice, white-hat contributor to the Web if you are conservative, swallowing the dogma that everything that's already a standard - from the <html> tag to IndexedDB - is excellent, or can be fixed with incremental improvements?

A+
Osvaldo