3 ms·

I've recently worked on optimizing a piece of integer-based AVX2 code which was running in a tight loop (dot product of 128-dimensional vectors with 8-bit compo

by zvrba 9y ago

I've recently worked on optimizing a piece of integer-based AVX2 code which was running in a tight loop (dot product of 128-dimensional vectors with 8-bit components). I inspected the assembly generated by MSVC17, and it did a really good job; no extra loads or stores or register spills. It was "as if" hand-written. > In my experience the compiler does a pretty poor job at this. A year ago I've worked with a guy optimizing ffmpeg's PRORES encoder; he also used AVX2 intrinsics. The result? 45% speed improvement (gcc) w/o any of the fuss of hand-coded assembly. [1] Sadly, the ffmpeg team suffers from the same prejudices as you, and won't accept intrinsics-based code, even though their "policy" is to accept all patches giving improvement of just a couple of percent points. EDIT: Ironically, they'd most probably accept the output of gcc -S og forfeit future optimizations implemented in gcc and other compilers. It is as if experienced programmers are forever stuck with their past experiences and won't ever look back. [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194575.html https://ffmpeg.org/pipermail/ffmpeg-devel/2016-May/194575.ht...

brigade 9y ago
And for a counterpoint that it's still the case that compilers can produce horrible codegen from intrinsics in 2017, this entire thread: http://www.realworldtech.com/forum/?threadid=166719 http://www.realworldtech.com/forum/?threadid=166719
- zvrba 9y ago
  Oh. He used 14 registers to manually unroll the inner loop. IME, on modern architectures, manual unrolling doesn't win you anything (benchmarked on, among other things, the above-mentioned dotproduct). I wouldn't be surprised if he got close to optimal code by just NOT manually unrolling. Fewer registers used, compiler less confused.
- rurban 9y ago
  I thought M.Matz recently fixed the register allocation mess, but apparently only the most egregious parts. See the old official pre-Matz gcc statements on the mess https://gcc.gnu.org/wiki/RegisterAllocation https://gcc.gnu.org/wiki/RegisterAllocation
angry_octet 9y ago
> It is as if experienced programmers are forever stuck with their past experiences and won't ever look back. This is totally the case. IME, anything that makes them step back from how they would normally solve the problem and rethink other approaches is of benefit. It is good if you can frame that as an appeal to their ego, 'cos people get defensive quickly. Sometimes they just feel out of their depth with the new and instinctively push back.
- zvrba 9y ago
  Ha, now I'm closely working with a "junior" developer and it's awesome. I try to teach him stuff underway, but usually let him find solutions to problems on his own (within boundaries). Sometimes he digs out really nice stuff that I note down and eventually add to my toolbox. It's almost like having my own research team :)

by zvrba 9y ago

brigade 9y ago

And for a counterpoint that it's still the case that compilers can produce horrible codegen from intrinsics in 2017, this entire thread: http://www.realworldtech.com/forum/?threadid=166719 http://www.realworldtech.com/forum/?threadid=166719

zvrba 9y ago
Oh. He used 14 registers to manually unroll the inner loop. IME, on modern architectures, manual unrolling doesn't win you anything (benchmarked on, among other things, the above-mentioned dotproduct). I wouldn't be surprised if he got close to optimal code by just NOT manually unrolling. Fewer registers used, compiler less confused.
rurban 9y ago
I thought M.Matz recently fixed the register allocation mess, but apparently only the most egregious parts. See the old official pre-Matz gcc statements on the mess https://gcc.gnu.org/wiki/RegisterAllocation https://gcc.gnu.org/wiki/RegisterAllocation

angry_octet 9y ago

> It is as if experienced programmers are forever stuck with their past experiences and won't ever look back. This is totally the case. IME, anything that makes them step back from how they would normally solve the problem and rethink other approaches is of benefit. It is good if you can frame that as an appeal to their ego, 'cos people get defensive quickly. Sometimes they just feel out of their depth with the new and instinctively push back.

zvrba 9y ago
Ha, now I'm closely working with a "junior" developer and it's awesome. I try to teach him stuff underway, but usually let him find solutions to problems on his own (within boundaries). Sometimes he digs out really nice stuff that I note down and eventually add to my toolbox. It's almost like having my own research team :)