4 ms·

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

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

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.
      - DarkShikari 18y ago
        "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.)

wmf 18y ago

Settle down; sometimes I just can't resist parodying the HN dogma. :-)