3 ms·

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

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

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