Re:Google removes SIMD.js support from Chromium
by angry_octet on Sunday June 04, 2017 @10:16AM
(#14481698)
> 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.
Re:Google removes SIMD.js support from Chromium
by zvrba on Sunday June 04, 2017 @12:54PM
(#14482351)
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 :)
Re:Google removes SIMD.js support from Chromium
by brigade on Sunday June 04, 2017 @05:50AM
(#14480575)
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
Re:Google removes SIMD.js support from Chromium
by zvrba on Sunday June 04, 2017 @06:08AM
(#14480637)
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.
Re:Google removes SIMD.js support from Chromium
by rurban on Sunday June 04, 2017 @06:14AM
(#14480660)
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
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.ht...