4 ms·

This was in 1999. C++ compilers have come a long ways since then. While there are still opportunities for hand-written asm to go and order of magnitude faster t

by necubi 3y ago

This was in 1999. C++ compilers have come a long ways since then. While there are still opportunities for hand-written asm to go and order of magnitude faster than C++, they're mostly around manual vectorization where the auto-vectorizer fails.

deleted 3y ago
[deleted]
mysteria 3y ago
And when that happens SIMD intrinsics are often used rather than going straight into raw assembly.
pjmlp 3y ago
Yes, younger devs grown up on the myth of C and C++ being always fast, have missed the days when inline Assembly was a higher count than pure C and C++ code. I have seen applications for MS-DOS, effectively using C as a Macro Assembler, only the data structures and high level logic was C as if Macro Assembler macros.
- loup-vaillant 3y ago
  > Yes, younger devs grown up on the myth of C and C++ being always fast, have missed the days when inline Assembly was a higher count than pure C and C++ code. And still is in VLC. (Okay, maybe not higher, but they do use a crapton of assembly in their decoders, and it does speed them up by a factor of 10 or so today.)
  - pjmlp 3y ago
    Video decoding has always been a prime example for SIMD stuff, however I wonder how much of that code VLC devs could wipeout, assuming hardware vídeo decoding being available everywhere.
  - hnthrowaway0328 3y ago
    Do you mean the VLC media player? Just curious is there any reason modern compilers don't beat assemblies or is that simply a legacy issue?
    - pjmlp 3y ago
      Compilers beat hand written Assembly for the general use cases. Now beating special use cases, like using vector instructions to parallel process video decoding streams is another matter. It is no accident that after all the efforts improving Java and .NET JITs for auto-vectorization across various vendors, both platforms now expose SIMD intrinsics as well.
      - hnthrowaway0328 3y ago
        Thanks for the explanation. Aside from vectorization is there anything else that handwritten assembly could be better? Assuming on modern CPUs and modern compilers.
        saagarjha 3y ago
        Sure, people who are good at assembly can often do register allocation and instruction selection better for small snippets of code. Or optimize based on guarantees the compiler can’t see or know about.
      - neonsunset 3y ago
        The choices and resulting codegen are fairly different. Only one of them works "properly" as of today. Though I'm open to be proven wrong once Panama vectors get stable in the Java land.
        pjmlp 3y ago
        They will only be out of preview when Valhala ships, as per roadmap. Then there is the whole issue when will they reach other implementations beyond OpenJDK, specially a very important alternative implementation running on many phones across the globe. Nevertheless the need to explicitly being allowed to write vector code is there.
- Keyframe 3y ago
  I was there, 3000 years ago, when C was considered bloated and slow. Times are a changing.
  - pjmlp 3y ago
    Unfortunately much of those optimizations are thanks to taking UB to full throttle.
ack_complete 3y ago
Even intrinsics didn't even necessarily work well. MSVC, in particular, was really, really bad back then with SIMD intrinsics -- any use of MMX or SSE intrinsics in VC6 would result in more than two-thirds of the generated code being move instructions, with a single value sometimes moved two or three times between ALU instructions. It was trivial to beat the compiler with hand-written assembly. MMX intrinsics were never fixed and SSE intrinsics weren't fixed until VS2010. For scalar code, it was more that the CPUs got better, as out-of-order execution starting with the Pentium Pro made instruction scheduling less important. The original Pentium CPU was an in-order design with two pipes where the second V pipe had significant restrictions, which was harder for compilers to deal with than the PPro/PII and its decoding pattern.
jb1991 3y ago
Assembly is still used in whole program coding to this day, for example some modern music synthesizers are written in assembly code.

by necubi 3y ago

deleted 3y ago

[deleted]

mysteria 3y ago

And when that happens SIMD intrinsics are often used rather than going straight into raw assembly.

pjmlp 3y ago

Yes, younger devs grown up on the myth of C and C++ being always fast, have missed the days when inline Assembly was a higher count than pure C and C++ code. I have seen applications for MS-DOS, effectively using C as a Macro Assembler, only the data structures and high level logic was C as if Macro Assembler macros.

loup-vaillant 3y ago
> Yes, younger devs grown up on the myth of C and C++ being always fast, have missed the days when inline Assembly was a higher count than pure C and C++ code. And still is in VLC. (Okay, maybe not higher, but they do use a crapton of assembly in their decoders, and it does speed them up by a factor of 10 or so today.)
- pjmlp 3y ago
  Video decoding has always been a prime example for SIMD stuff, however I wonder how much of that code VLC devs could wipeout, assuming hardware vídeo decoding being available everywhere.
- hnthrowaway0328 3y ago
  Do you mean the VLC media player? Just curious is there any reason modern compilers don't beat assemblies or is that simply a legacy issue?
  - pjmlp 3y ago
    Compilers beat hand written Assembly for the general use cases. Now beating special use cases, like using vector instructions to parallel process video decoding streams is another matter. It is no accident that after all the efforts improving Java and .NET JITs for auto-vectorization across various vendors, both platforms now expose SIMD intrinsics as well.
    - hnthrowaway0328 3y ago
      Thanks for the explanation. Aside from vectorization is there anything else that handwritten assembly could be better? Assuming on modern CPUs and modern compilers.
      - saagarjha 3y ago
        Sure, people who are good at assembly can often do register allocation and instruction selection better for small snippets of code. Or optimize based on guarantees the compiler can’t see or know about.
    - neonsunset 3y ago
      The choices and resulting codegen are fairly different. Only one of them works "properly" as of today. Though I'm open to be proven wrong once Panama vectors get stable in the Java land.
      - pjmlp 3y ago
        They will only be out of preview when Valhala ships, as per roadmap. Then there is the whole issue when will they reach other implementations beyond OpenJDK, specially a very important alternative implementation running on many phones across the globe. Nevertheless the need to explicitly being allowed to write vector code is there.
Keyframe 3y ago
I was there, 3000 years ago, when C was considered bloated and slow. Times are a changing.
- pjmlp 3y ago
  Unfortunately much of those optimizations are thanks to taking UB to full throttle.

ack_complete 3y ago

Even intrinsics didn't even necessarily work well. MSVC, in particular, was really, really bad back then with SIMD intrinsics -- any use of MMX or SSE intrinsics in VC6 would result in more than two-thirds of the generated code being move instructions, with a single value sometimes moved two or three times between ALU instructions. It was trivial to beat the compiler with hand-written assembly. MMX intrinsics were never fixed and SSE intrinsics weren't fixed until VS2010. For scalar code, it was more that the CPUs got better, as out-of-order execution starting with the Pentium Pro made instruction scheduling less important. The original Pentium CPU was an in-order design with two pipes where the second V pipe had significant restrictions, which was harder for compilers to deal with than the PPro/PII and its decoding pattern.

jb1991 3y ago

Assembly is still used in whole program coding to this day, for example some modern music synthesizers are written in assembly code.