6 ms·

I wonder if they've considered using libjpeg-turbo instead of libjpeg9a, which comes with a lot of SIMD optimization and is regarded to be 2x-5x as fast as IJG'

I wonder if they've considered using libjpeg-turbo instead of libjpeg9a, which comes with a lot of SIMD optimization and is regarded to be 2x-5x as fast as IJG's implementation.[1] [1] http://www.libjpeg-turbo.org/About/Performance http://www.libjpeg-turbo.org/About/Performance

listic 11y ago
My thought as well. As far as I understand, these intrinsics map to SSE instructions (they are 128-bit). One could use the later AVX (256-bit, found in server chips since 2011). Probably they decided to start with the lowest common denomintor of SSE, because they don't have AVX in all of their servers? The term SIMD is generic.
- unwind 11y ago
  That is explicitly mentioned in the article: Note: we could also choose to use 256-bit wide YMM registers here, but that would only work on the newest CPUs, while gaining little performance. I'm not saying they're right and you're wrong, but you make it sound as if they never even considered AVX.
  - liotier 11y ago
    > Note: we could also choose to use 256-bit wide YMM registers here, but that would only work on the newest CPUs, while gaining little performance. Should that be an #ifdef ?
    - booblik 11y ago
      There is an #ifdef in the final code on github
    - repsilat 11y ago
      Maybe if the machine running the code is the machine that compiles it, or if you have a good way to send processor-specific binaries to the right places. More useful, I think, would be a runtime check far enough up the stack (i.e., away from tight loops) that it doesn't affect performance. Probably doesn't even need to be that high, it'll branch-predict correctly every time but the first iteration, and the binary bloat probably won't hurt your icache because the number of instructions you ever actually execute stays more or less the same.
- xioxox 11y ago
  AVX 2 is required to get the wider integer instructions, so this would require Haswell processors.
  - deleted 11y ago
    [deleted]
jgrahamc 11y ago
We considered libjpeg-turbo, but the performance of jpegtran there is much unchanged. If you look at the Huffman encoding function it is exactly the same. Applying the optimizations to libjpeg-turbo also yield a 2x performance improvement for our usage.

listic 11y ago

My thought as well. As far as I understand, these intrinsics map to SSE instructions (they are 128-bit). One could use the later AVX (256-bit, found in server chips since 2011). Probably they decided to start with the lowest common denomintor of SSE, because they don't have AVX in all of their servers? The term SIMD is generic.

unwind 11y ago
That is explicitly mentioned in the article: Note: we could also choose to use 256-bit wide YMM registers here, but that would only work on the newest CPUs, while gaining little performance. I'm not saying they're right and you're wrong, but you make it sound as if they never even considered AVX.
- liotier 11y ago
  > Note: we could also choose to use 256-bit wide YMM registers here, but that would only work on the newest CPUs, while gaining little performance. Should that be an #ifdef ?
  - booblik 11y ago
    There is an #ifdef in the final code on github
  - repsilat 11y ago
    Maybe if the machine running the code is the machine that compiles it, or if you have a good way to send processor-specific binaries to the right places. More useful, I think, would be a runtime check far enough up the stack (i.e., away from tight loops) that it doesn't affect performance. Probably doesn't even need to be that high, it'll branch-predict correctly every time but the first iteration, and the binary bloat probably won't hurt your icache because the number of instructions you ever actually execute stays more or less the same.
xioxox 11y ago
AVX 2 is required to get the wider integer instructions, so this would require Haswell processors.
- deleted 11y ago
  [deleted]

jgrahamc 11y ago

We considered libjpeg-turbo, but the performance of jpegtran there is much unchanged. If you look at the Huffman encoding function it is exactly the same. Applying the optimizations to libjpeg-turbo also yield a 2x performance improvement for our usage.