3 ms·

What is still done in ASM Code that needs to be fast? Intel, ARM, and other chip designers dedicate huge chunks of their chip to vector SIMD processors for a

What is still done in ASM Code that needs to be fast? Intel, ARM, and other chip designers dedicate huge chunks of their chip to vector SIMD processors for a reason. SSE, Altivec, and NEON assembly implementations of DSP functions can easily be up to 40 times faster than a naive scalar version. And even if you can't take advantage of SIMD, a competent programmer can almost always beat the compiler on small critical functions and loops. Doubly so on architectures where compilers are typically terrible, and instructions are complex and individually very powerful (ARM). Triply so in cases where the compiler simply won't "do the right thing" no matter how much you nudge it, such as aliasing and unpredictable branches.

minimax 15y ago
You can get to most of the special purpose x86 vector instructions in GCC without dropping down to assembly. http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Vector-Extensions.html http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Vector-Extension... http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/X86-Built_002din-Functions.html http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/X86-Built_002din...
- DarkShikari 15y ago
  Vector extensions are terrible: they're too high-level an abstraction because they don't expose individual instructions, and SIMD instructions are "weird" enough that you can't get reasonable performance by expecting the compiler to magically do the right thing. There's no gcc vector equivalent of psadbw, for example, and I doubt the compiler is even capable of generating it. Intrinsics are passable, but still have two core problems. First of all, the compiler is atrocious at register allocation: it will often spill far more than necessary, and even when it doesn't, it will usually spill the wrong things. Secondly, they're way harder to write than straight assembly, far less flexible, and are nigh-unreadable, so why bother?
  - minimax 15y ago
    I'm not sure you looked at what I posted. __builtin_ia32_psadbw is right there on the list of builtins. I've used __builtin_ia32_psadbw128 in GCC myself. It compiles directly to PSADW instructions. Perhaps you confused what I was talking about with GCC's auto-vectorization? edit: Just realized that you're the x264 guy and it's unlikely you misunderstood me. Still I think my point about psadbw stands.
    - DarkShikari 15y ago
      I'm not sure you looked at what I posted. __builtin_ia32_psadbw is right there on the list of builtins. I've used __builtin_ia32_psadbw128 in GCC myself. It compiles directly to PSADW instructions. Perhaps you confused what I was talking about with GCC's auto-vectorization? Those aren't gcc vectors, those are intrinsics. Vectors use something like this: typedef uint32_t v4si __attribute__((vector_size (16))); v4si v16 = {v,v,v,v}; __builtin functions that act on __m128 values are separate from "GCC vector instructions".

minimax 15y ago

You can get to most of the special purpose x86 vector instructions in GCC without dropping down to assembly. http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Vector-Extensions.html http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Vector-Extension... http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/X86-Built_002din-Functions.html http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/X86-Built_002din...

DarkShikari 15y ago
Vector extensions are terrible: they're too high-level an abstraction because they don't expose individual instructions, and SIMD instructions are "weird" enough that you can't get reasonable performance by expecting the compiler to magically do the right thing. There's no gcc vector equivalent of psadbw, for example, and I doubt the compiler is even capable of generating it. Intrinsics are passable, but still have two core problems. First of all, the compiler is atrocious at register allocation: it will often spill far more than necessary, and even when it doesn't, it will usually spill the wrong things. Secondly, they're way harder to write than straight assembly, far less flexible, and are nigh-unreadable, so why bother?
- minimax 15y ago
  I'm not sure you looked at what I posted. __builtin_ia32_psadbw is right there on the list of builtins. I've used __builtin_ia32_psadbw128 in GCC myself. It compiles directly to PSADW instructions. Perhaps you confused what I was talking about with GCC's auto-vectorization? edit: Just realized that you're the x264 guy and it's unlikely you misunderstood me. Still I think my point about psadbw stands.
  - DarkShikari 15y ago
    I'm not sure you looked at what I posted. __builtin_ia32_psadbw is right there on the list of builtins. I've used __builtin_ia32_psadbw128 in GCC myself. It compiles directly to PSADW instructions. Perhaps you confused what I was talking about with GCC's auto-vectorization? Those aren't gcc vectors, those are intrinsics. Vectors use something like this: typedef uint32_t v4si __attribute__((vector_size (16))); v4si v16 = {v,v,v,v}; __builtin functions that act on __m128 values are separate from "GCC vector instructions".