Nativeclient: run x86 native code in Web Applications.

http://code.google.com/p/nativeclient/

by DaniFong • 18 years ago

18 19 18 years ago

code.google.com

tptacek7• 18 years ago

In the long run, I don't see how this is much more useful than JIT-ed Java bytecode. In both cases, you're relying on a heavyweight browser plugin to execute code. Nativeclient runs direct x86 code, after scrubbing it down to a subset of x86. JIT Java takes a bytecode stream and generates a safe x86 instruction stream.

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.

wmf3• 18 years ago

There's a lot of legacy C code (e.g. x264) that would be expensive to rewrite in Java. Also, Java JITs aren't very good at generating SSE code.

DarkShikari5• 18 years ago

"Legacy" C code?

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.

DaniFong2• 18 years ago

In the long run, yes, it's pretty much the same as JIT-ed Java. But technology always seems to be a moving target, and native, compiled binaries are probably going to be important for a long time.

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.

tptacek7• 18 years ago

The applet sandbox was in the same position. The limitation has been security and compatibility. As the applet sandbox has been extended (for instance, with QT4J), both security and compatibility have become problems. I don't see how NaCL avoids those.

wmf3• 18 years ago

Dupe: http://news.ycombinator.com/item?id=390352

DaniFong2• 18 years ago

Whoops, my mistake.

drwh0• 18 years ago

shall we call this activeG?

scumola• 18 years ago

Yet another way to run unsigned code, er viruses in your browser. :)

Nativeclient: run x86 native code in Web Applications.

Related Stories