Mozilla mimics Google's native code demo in JavaScript

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 …

[Anonymous Coward]

Oh come on

Maybe they managed to achieve 50% of native speeds in one particular test, and by tailoring their javascript code to their javascript interpreter, but I find it hard to believe that javascript can be in the same league as native code for most cases.

Also, if their new extension translated javascript to native code, then what is really so terrible about an extension that allows native code to be delivered from the server (assuming that security issues are dealt with). You could just say that the optimization was being done on the server instead of the client.

[Richard Lloyd]

Why native code isn't great...

Whilst native code might well give you the fastest speed, it has two obvious issues. One is security (i.e. it has to be sandboxed very well) and two is portability. Do you really think that anything developed for a native code plugin will be available for *all* platforms that the browser runs on (i.e. Windows, Mac, Linux, 32-bit, 64-bit, never mind extra platforms that the Chromium source code may have been ported to)? I bet it wouldn't be in most cases.

[Anonymous Coward]

native code

I don't quite buy into the "native code bad - javascript good" argument concerning safety.

I can recall plenty of JavaScript related malware attacks that have left several browsers vulnerable. JavaScript needs to be sandboxed too.

Last time I checked, there were no decent JavaScript tools out there. I had to make sure every branch of my code would execute without errors, and as a bonus I had to check every browser that my site was supposed to support. HTML/JavaScript is a tough target platform for developers.

Better then to make sure that running native code with guest priviligies is a safe thing to do. Or resort to the best of both worlds: .Net. Which provides fairly decent development tools, a very nice platform and quite OK performance.

If you want to make an application, you do not start by making the user interface in a word processor. Which is exactly what we do when targetting the web, except many of us do the word processing bit by hand (use notepad instead of word so we get to see the tags -- whohooo!).

[Nathan 6]

Someone should do this as a Java Applet

Wonder what the performance would be if this were done as a Java Applet. I am guess pretty close to native speed.

[Tom Chiverton 1]

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.

[Anonymous Coward]

Java, JavaScript and Native Code Performance

The major problem with managed languages is that they are using memory in a very inefficient way. One reason for that is the use of Garbage Collection. This does not show up, if the computer has ten times more memory than required; acutally it is much speedier to perform new() in Java than in C++.

But if the physical memory approaches program memory requirements, the GC must run all the time and that slows down Java programs dramatically. It also kills realtime performance.

Another problem is that you cannot have structure arrays and nested structures. This can easily lead to bad cache usage patterns and consequential performance losses. In C++ you have all of that and also stack-allocated variables of any type. That means the memory you will access soon probably is already in the cache. Extremely fast.

Finally, C++ has synchronous destructors which are great to manage resources like file or socket handles from a programmer's point of view. Also, this is a crucial part of efficient memory usage.

So, tweaked benchmarks can deceive you into thinking Java or JavaScript can be competitive, when this is not really true. Just run a non-trivial Java GUI app and compare it with a C++/Qt/wxWidget/MFC based app in terms of responsiveness and memory usage.

This will remove any doubts about Java's inferiority.

[Anonymous Coward]

native client: is it about speed?

or is it about the ease of porting apps to a browser-based software distribution model?

Fast javascript execution is fine if your app is already javascript. What about if it is written in C? Perhaps native-code is easier to port to than javascript.

I would guess Google is trying to bypass the importance of the OS environment by making software distribution web-based. Centralise app distribution to URLs, centralise data storage but have distributed processing and rendering. It looks like the web model but without the javascript rewrite. That seems like a good way for google to bypassing windows, rather than fighting it.

[Defiant]

Sheep

Still wont beat Opera 10.60

[Anonymous Coward]

Sounds good

The performance sounds very promising, and it's a preferable solution to having to write native code apps in different languages (Google Native, ActiveX) and then still not having it work across all browsers. Why would I want to write something for Google's native code system if it only works on a small fraction of browsers out there? It's certainly a browser in the minority in corporate environments in particular.

[Anonymous Coward]

The distinction isn't really JavaScript versus "native code"

It's JavaScript versus C.

Today's browsers are so huge and bloated that you might as well chuck in a compiler or two. Then anything that can be translated into native code will be.

Carefully written JavaScript translated by the browser could potentially run faster than precompiled C code because the browser knows exactly what architecture it's running on, though I suppose the precompiled code could do runtime tests if you don't mind it being several times bigger, and theoretically the "native code" could include hand-written assembler, which is however unlikely, nowadays.

You can get the speed using either approach. The question is, how hard is it to get the speed while maintaining reliability, portability, etc.

[Anonymous Coward]

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).

[Henry Wertz 1]

compiler versus compiler

@tom c, in general I would have agreed. However, what you actually have here is a Javascript engine that uses a just-in-time compiler to turn the javascript into assembly before it runs it... and "native code plugin" that takes C code and turns it into assembly before it runs it. I doubt the C compiler is going to have agressive flags turned on (ala gentoo) so it won't be generating SSE code or anything even if the CPU supports it.

[BlueGreen]

titles, titles, tiles, tyres, troubles, tomatoes, traction, whyest thou a title thee demands

I don't see that recursion or heavily nested code is any intrinsic barrier to compilation. The guaranteed killer is eval( ), although idiosyncratic programming styles are likely to mess it up, so that's my functional stuff down the toilet...

@jlocke: the issue of garbage collection and managed languages etc is an interesting one, but you oversimplify. One language can do a new( ) faster than another by using various tricks and by ignoring amortised costs, such as the GC sweep -- compacting GC'ers can do an allocation in a single pointer-bump, but the sweep phase is another matter.

> Another problem is that you cannot have structure arrays and nested structures. This can easily lead to bad cache usage patterns and consequential performance losses. In C++ you have all of that and also stack-allocated variables of any type. That means the memory you will access soon probably is already in the cache. Extremely fast.

Whether this leads to a slowdown depends on access patterns rather than layout patterns, although certainly you would expect that funny layouts lead to funny access patterns which lead to poor performance, it's not a given. Also there are usually tricks you can pull such as flattening arrays. But rather critically, Java is not tied to the JVM. If you wish to compile Java directly to the native machine then do so.

Saying one language is better than another is pretty meaningless, it depends on intended use. If the car better than an elephant? It depends on whether you're going to the shops in the UK, or punting tree trunks around in an Indonesian forest. And manually handling memory efficiently and correctly, that gets tremendously difficult as the code grows.

And in any event IME the programmer's skill and knowledge seems to be the overriding factor in program efficiency. I really want to emphasise that point.

And on:

> 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.

Any justification for this?

> In some cases, this even makes for a 1000% performance improvement.

That's a big claim.

re. GC read the discussion between myself and /sed gawk/ at <http://forums.theregister.co.uk/forum/2/2010/02/17/top_25_programming_errors/#c_699356>.

[Anonymous Coward]

GC, Assembler

Regarding GC-languages, please point me to a non-trivial IDE or CAD package done in Java or .Net. IF they exist (like Eclipse or VS2010) they are consuming memory very liberally. In the CAD space, I am not aware of a serious Java alternative. CATIA V5, for example, is completely done in C++. I was part of that team and they do some clever things with macros (containers) but don't use templates. It is a huage system, but loads pretty quickly. Normally it uses about 150M of RAM, but the equivalent Java app would certainly gobble up 700M and take 15mins to load.

Regarding assembly - try some specialized signal processing apps in A) C and B) SSE2 assembly. Spend as much time as you like. B) will typically be 10x faster. That's 1000%. I know because I had to build an audio app doing something FFT-like and had two code versions A and B. The assembly portion were just 100 lines, so it was well worth the effort.

[BlueGreen]

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.