14 ms·

> wouldn't 20 y/o open source software as prevalent as FreeType have optimized those code paths You'd be surprised how often SIMD goes unused. libpng, for exam

> wouldn't 20 y/o open source software as prevalent as FreeType have optimized those code paths You'd be surprised how often SIMD goes unused. libpng, for example, doesn't use it on x86… Outside of games, scientific computing, and a few other fields, it's notable how little of the hardware in our devices actually gets put to use.

zzleeper 10y ago
I wonder whose fault is that.. if you build a feature that almost on one will use, then is the 'API' too arcane, everyone too lazy, or are there no tools available to ease the pain?
- 14113 10y ago
  No tools available, or at least, none that are easy to use. It's the classic parallelism problem: tools are either too low level (e.g. CUDA/OpenCL for the GPU space) for day to day developers to leverage effectively, or too high level to provide the performance in the other 10% of the codebase, wiping out your parallelism benefits. In this space, the low level alternative is manually writing SIMD x86 instructions, or using a similarly low level C library to do the same. The alternative is switching to something like haskell and using one of their high level array manipulation DSLs. In the first case, you have to explicitly manage the parallelism, and there _will_ be bugs there, in the second case you probably lose more performance in the other 90% of your application by switching to (say) haskell than you gain in parallelism. In terms of automation, SIMD is hard to automatically implement (i.e. through the compiler) with a lot of traditional programming languages (e.g. C), and hard to add to dynamic languages, as you end up adding extra code paths/jit passes for each new type of simd/parallelism hardware construct available.
- moosingin3space 10y ago
  I believe that C is in part to blame, because the ANSI C abstract machine describes a single-threaded processor.
  - vardump 10y ago
    SIMD is not about threading. Of course you can multithread it too, just like any other code.
    - moosingin3space 10y ago
      My comment was responding to the concept that "it's notable how little of the hardware in our devices actually gets put to use".
stuaxo 10y ago
Interesting, especially seeing how other architectures do it, I don't know if libpng does google summer of code, but that would be a great suggestion for a GSOC.
viraptor 10y ago
> libpng, for example, doesn't use it on x86… Do you mean doesn't use it explicitly? If so, GCC is still happy to find quite a few spots to automatically inject it. On my arch system: $ objdump -d /usr/lib/libpng.so | grep -c xmm 316 Then again, gif doesn't seem to get even that, so maybe there is something in libpng? $ objdump -d /usr/lib/libgif.so | grep -c xmm 0
- pcwalton 10y ago
  Explicitly, for filtering.
- mayoff 10y ago
  gcc and clang generate SSE2 instructions for scalar (non-SIMD) arithmetic, depending on the target architecture and compiler flags. For x86_64 targets, the calling convention puts floating point arguments in xmm registers, so the compilers must use SSE2 (and it's faster than x87 anyway). That's what you're seeing. If you look at the instructions in libpng.so that mention xmm registers, you'll see that they aren't SIMD instructions.
warmwaffles 10y ago
It's funny, anecdotally I've seen developers say that it should be the compiler's job to insert SIMD instructions and do optimizations. But many don't understand SIMD and think it's something as simple as replacing a few instructions.

zzleeper 10y ago

I wonder whose fault is that.. if you build a feature that almost on one will use, then is the 'API' too arcane, everyone too lazy, or are there no tools available to ease the pain?

14113 10y ago
No tools available, or at least, none that are easy to use. It's the classic parallelism problem: tools are either too low level (e.g. CUDA/OpenCL for the GPU space) for day to day developers to leverage effectively, or too high level to provide the performance in the other 10% of the codebase, wiping out your parallelism benefits. In this space, the low level alternative is manually writing SIMD x86 instructions, or using a similarly low level C library to do the same. The alternative is switching to something like haskell and using one of their high level array manipulation DSLs. In the first case, you have to explicitly manage the parallelism, and there _will_ be bugs there, in the second case you probably lose more performance in the other 90% of your application by switching to (say) haskell than you gain in parallelism. In terms of automation, SIMD is hard to automatically implement (i.e. through the compiler) with a lot of traditional programming languages (e.g. C), and hard to add to dynamic languages, as you end up adding extra code paths/jit passes for each new type of simd/parallelism hardware construct available.
moosingin3space 10y ago
I believe that C is in part to blame, because the ANSI C abstract machine describes a single-threaded processor.
- vardump 10y ago
  SIMD is not about threading. Of course you can multithread it too, just like any other code.
  - moosingin3space 10y ago
    My comment was responding to the concept that "it's notable how little of the hardware in our devices actually gets put to use".

stuaxo 10y ago

Interesting, especially seeing how other architectures do it, I don't know if libpng does google summer of code, but that would be a great suggestion for a GSOC.

viraptor 10y ago

> libpng, for example, doesn't use it on x86… Do you mean doesn't use it explicitly? If so, GCC is still happy to find quite a few spots to automatically inject it. On my arch system: $ objdump -d /usr/lib/libpng.so | grep -c xmm 316 Then again, gif doesn't seem to get even that, so maybe there is something in libpng? $ objdump -d /usr/lib/libgif.so | grep -c xmm 0

pcwalton 10y ago
Explicitly, for filtering.
mayoff 10y ago
gcc and clang generate SSE2 instructions for scalar (non-SIMD) arithmetic, depending on the target architecture and compiler flags. For x86_64 targets, the calling convention puts floating point arguments in xmm registers, so the compilers must use SSE2 (and it's faster than x87 anyway). That's what you're seeing. If you look at the instructions in libpng.so that mention xmm registers, you'll see that they aren't SIMD instructions.

warmwaffles 10y ago

It's funny, anecdotally I've seen developers say that it should be the compiler's job to insert SIMD instructions and do optimizations. But many don't understand SIMD and think it's something as simple as replacing a few instructions.