4 ms·

Nativeclient: run x86 native code in Web Applications.

18 points by DaniFong 18y ago

tptacek 18y 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.
- wmf 18y 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.
  - DarkShikari 18y 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.
    - tptacek 18y ago
      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 18y ago
        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 18y ago
        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 18y ago
        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 18y ago
        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.
        18y ago
    - wmf 18y ago
      Settle down; sometimes I just can't resist parodying the HN dogma. :-)
- DaniFong 18y 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.
  - tptacek 18y 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.
wmf 18y ago
Dupe: http://news.ycombinator.com/item?id=390352 http://news.ycombinator.com/item?id=390352
- DaniFong 18y ago
  Whoops, my mistake.
drwh0 18y ago
shall we call this activeG?
scumola 18y ago
Yet another way to run unsigned code, er viruses in your browser. :)

18 points by DaniFong 18y 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.

wmf 18y 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.
- DarkShikari 18y 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.
  - tptacek 18y ago
    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 18y ago
      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 18y ago
        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 18y ago
        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 18y ago
        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.
        18y ago
  - wmf 18y ago
    Settle down; sometimes I just can't resist parodying the HN dogma. :-)
DaniFong 18y 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.
- tptacek 18y 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.

wmf 18y ago

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

DaniFong 18y ago
Whoops, my mistake.

drwh0 18y ago

shall we call this activeG?

scumola 18y ago

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