Mozilla mimics Google's native code demo in JavaScript
Time for a Jäger shot
Cloud storage: Lower cost and increase uptime
Velocity Mozilla believes that its JavaScript engine isn't that far from matching the performance of Google's Native Client plug-in, which eschews web standards to run native code inside the browser.
Speaking today at the net-performance obsessed Velocity conference in Santa Clara, California, Mozilla open source evangelist Chris Blizzard showed off a Firefox JavaScript demo meant to mimic a test that Google uses to show off Native Client, and he said that even with today's Firefox, Mozilla comes within 50 per cent of the performance of native code.
In a web video here, Google shows off a Native Client incarnation of a web-based photo editing app that lets you apply filters in realtime. Blizzard and Mozilla have ported the same app to JavaScript, achieving performance of about seven frames a second versus Google's 15 frames a second.
As Blizzard said, the JavaScript photo demo was "pretty snappy."
"We've started to realize we can do things that would normally be done in native code," Blizzard said. "But we can do them in JavaScript." Just yesterday, Mozilla vice president of product Jay Sullivan told us that the open source outfit has no intention of bundling a Native Client-like plug-in with its browser, preferring to advance standard technologies like HTML5 and JavaScript.
As Blizzard pointed out, the next version of Firefox – Firefox 4, due in beta any day now – will include a new extension to the browser's existing JavaScript engine. Dubbed JaegerMonkey, the extension will operate alongside TraceMonkey – an extension that debuted with Firefox 3.5 last year – interpreting JavaScript code unsuited to "tracing."
TraceMonkey speeds performance by detecting code loops and converting them into assembly language. "We find places where code gets executed more than once," Blizzard said. "We basically optimize that code and trace it to native code."
But there are cases where this sort of thing just doesn't work. This happens with, say, recursion or heavily nested code. As it stands, when tracing fails, Firefox falls back on an interpreter that runs JavsScript at circa 2007 speeds.
With JaegerMonkey, Mozilla adds a Just-in-Time (JIT) engine much like those used by the other major browsers. The extension is actually based on the Nitro JIT used by Apple Safari. Firefox will still do tracing – something other browsers don't do – but it will be able to fall back on the baseline JIT, converting entire methods into assembly language.
"The important thing to realize is that we know we have a lot of things we can to do to optimize for really intensive web apps that will get us within [striking distance] of native code speed," Blizzard said. ®
COMMENTS
Assembly Coding
If you want to get the last 70 % performance out of an Intel or AMD CPU you need to handcode your innermost loops in assembly. And use things like SSE, of course.
In some cases, this even makes for a 1000% performance improvement. The whole JIT idea has not taken off yet. It might work with LLVM's RTL and a C++-like language, but it will never do that with Java, JavaScript or .Net.
And whatever you do, compilation is very, very CPU-intensive. It should not be done for each and every client again. Rather, use RTL and Compilation Providers/Caches. Which can be inside or outside your intranet. Secure it with digital signatures and trusted providers (like Google, MS, Oracle, IBM, Rhat, Canonical, etc).
flash
If you do it in Flash (like many sites let you do), you can apply the filters in real time, full 24fps. Oh well.
re: GC, Assembler
Java != GC, GC != Java
> IF they exist (like Eclipse or VS2010) they are consuming memory very liberally
Well eclipse is 'written primarily in Java' <http://en.wikipedia.org/wiki/Eclipse_software> and VS2010 is written in C++ & C# <http://en.wikipedia.org/wiki/Visual_Studio_2010> which is presumably a mix of GC & non-GC.
As to their bloat, I use emacs (GC'd lisp) which is tons smaller than those monsters. Perhaps bloat isn't solely down to use of GC or a given language? Maybe featureitis?
Re. CAD I can't, but I note that Autocad has a GC'd lispy front end. Horses for courses perhaps.
There's also wings, written in erlang I believe <http://en.wikipedia.org/wiki/Wings_3D> but it's more a personal project than commercially important software. It can export to Blender which per the wiki page uses python for the scripting - presumably because a slower but higher-level GC'd lang is more appropriate for end use than C? Horses for courses like I said.
I worked on a system which was GC'd using refcounting. It was horrible performance-wise but the lead programmers thought it was worthwhile when they started & felt they'd made the right decision at the end. It was arguably the crappiest form of GC to implement but it worked for them because it allowed them to concentrate on the relevant deliverables, not low-level pointer management, the delays & general bugs of which would have sunk the project & the company, I guarantee it.
Horses/courses. A feature or language's superiority is in the context of its use, not intrinsic to the language.
Regarding SSE, well, you have the edge over me with your experience. I'd only note that I'd not expect signal processing stuff to be done in jscript, but that's maybe not a fair criticism as flops are useful in many areas.
IT infrastructure monitoring strategies
What you need to know about cloud backup
Enabling efficient data center monitoring
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
