Nativeclient: run x86 native code in Web Applications.
code.google.com
code.google.com
In both cases, the plugin has to provide a system call interface to do anything "interesting" with the client. That system call interface is either too trivial to enable interesting applications, or so complicated that it, not the instruction analyzer, is going to be the primary attack surface of the plugin.
It is shocking, though.
There's a good reason we wrote x264 in C: can you imagine trying to write a performance-critical app like that in Java?
The assembly alone contributes a 5-7x performance increase: the difference between running real-time HDTV encoding and being stuck making video for iPods. It is literally the difference between having a working business model and not having a working business model.
People in the web world always think they can get away with purely interpreted and JIT'd languages until they realize they actually have do things like encode and decode video, and suddenly even pure C isn't anywhere near fast enough.
Obviously today's bytecode JITs aren't faster than C or C+assembly. But if you're going to pick a platform to innovate on, I'm saying it's not a total no-brainer to think about JIT (well-understood and working) instead of x86 verification (poorly-understood, science project).
Though I would quite confidently say that our C code is quite a bit faster than the naive Java equivalent, for a number of reasons, mostly because all the critical sections have been hand-optimized using explicit write-combining, branchless algorithms, lookup tables, etc. Of course, one can do most of this in Java, but I still would imagine it would be somewhat slower simply because one has less control over the generated assembly.
JITs are well understood and work--but some tasks are simply not well-suited to them. Sometimes you need SIMD. And if you're suggesting handwritten assembly in Java, that completely comes back to the same problem, since you need to verify that the x86 code is safe (etc etc).
I'm not saying NaCL is unsafe, just that there are easier ways to get some of the same benefits.
Compilers are dumb. This gets an order of magnitude worse when you expose them to SIMD.
If I can't write assembly in your language and have it run exactly as I wrote it, in the order I wrote it, with the instructions I used, your language is not suitable for performance-critical applications like the aforementioned.
And my assembly includes things like computed jumps to one of 16 functions based on known variables, which you cannot write using intrinsics (you're forced to, at best, do a jump table instead, since you don't know the exact size of each function).
(Now, I do fully understand the argument that JIT is probably easier than x86 code verification, and that you could get "good enough" code using intrinsics in a JIT. But of course, that requires convincing everyone who already wrote their code in C and asm to go rewrite it for your JIT.)
Your second two paragraphs are mostly subjective. I also think you've staple gunned your design sensibility to 2008; Java (for instance) is over 10 years old. Do you think that in 2018, you'll be hand-carving computed jumps and manually re-ordering instruction sequences just to decode video? If Perl isn't decoding HD video in 2018, I'm going to be disappointed.
Clearly, pure interpreted runtimes are giving way to "modern" (ie, "standard in academia since 1995") native code runtimes. Java has been there forever. Along with the cost of proving out and converting developers to a verified x86 plugin, you also need to factor in the fact that virtually every browser in the world has Java, and is an auto-update away from a much better JVM.
The real issue is, I don't think anyone's going to care about this. I could be wrong, obviously.
"In a few years any CPU will be able to decode DVDs easily. SIMD will be obsolete!"
And every single time, a few years pass, and it never, ever happens, because CPUs don't get faster in a vacuum. Just as much, our demand for performance increases.
In fact, right now, I'd say that the demand for performance is outpacing CPU development. The CPU requirement for 1080p H.264 from a Blu-ray disc is easily 20-40 times greater than the video from a DVD. CPU's haven't gotten that much faster in the meantime, forcing graphics card makers to add hardware acceleration, just as in the earliest days of DVD playback.
The interesting thing is that now the plugin developer controls the system call interface, not the OS. They could develop a suitable layer of abstraction for a lot of things that you'd ordinarily need an OS for, and would go out of your mind to port.