Oh come on
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.
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!).
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.
If you do it in Flash (like many sites let you do), you can apply the filters in real time, full 24fps. Oh well.
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.
This will remove any doubts about Java's inferiority.
native client: is it about speed?
or is it about the ease of porting apps to a browser-based software distribution model?
Still wont beat Opera 10.60
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.
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.
You can get the speed using either approach. The question is, how hard is it to get the speed while maintaining reliability, portability, etc.
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.
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).
compiler versus compiler
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.
> 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>.
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.
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.