

Nativeclient: run x86 native code in Web Applications. - DaniFong
http://code.google.com/p/nativeclient/

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

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

~~~
DarkShikari
"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.

~~~
tptacek
I'm not sure why, in the abstract, the performance you're talking about isn't
just a set of bytecode intrinsics away from being realizeable in Java. Your
5-7x performance increase is presumably from SIMD, not instruction scheduling.

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

~~~
DarkShikari
Yes, the performance increase is mostly from SIMD (though not entirely: we
have a few assembly functions with minimal to no SIMD that offer a great
improvement over pure C).

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

~~~
tptacek
It doesn't come back to the same problem at all; SIMD assembly generated from
Java bytecode intrinsics doesn't have the same verification problems that x86
does. That's why Google's paper had a section structured as a formal proof.
JITs are inherently safer than verified x86.

I'm not saying NaCL is unsafe, just that there are easier ways to get some of
the same benefits.

~~~
DarkShikari
Intrinsics are no substitute for handwritten assembly, and anyone who has
actually tried to use them should know this.

Compilers are _dumb_. This gets an order of magnitude worse when you expose
them to SIMD.

~~~
tptacek
You seem to be stuck on compilers; I'm talking about virtual machine
architectures. You're also not making a case for verified x86 so much as you
are for generic native code.

~~~
DarkShikari
"Generic native code" is quite literally a contradiction in terms. What kind
of virtual machine are you proposing that doesn't require translation of
instructions from some intermediate bytecode instruction set into x86 (a
process sometimes called "compiling")?

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

~~~
tptacek
I have no idea what your first paragraph means.

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.

~~~
DarkShikari
Every few years, they tell us that performance won't matter anymore in a few
years, because CPUs keep getting faster.

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

~~~
tptacek
If you (generously) count MMX, x86 SIMD is still younger than the JVM, or even
JIT JVM. But I agree that "hardware acceleration" is going to take up a lot of
the slack here; all the more reason not to chase unproven performance tricks
like verified x86.

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

------
wmf
Dupe: <http://news.ycombinator.com/item?id=390352>

~~~
DaniFong
Whoops, my mistake.

------
drwh0
shall we call this activeG?

