4 ms·
These instructions will be around for a long time, but their performance attributes will change in 5 minutes when Intel releases the next wave of processors. I
by jblow 8y ago
These instructions will be around for a long time, but their performance attributes will change in 5 minutes when Intel releases the next wave of processors.
I think given the current state of things it would be irresponsible for compilers to generate heavy instructions unless asked. Forget trying to be smart about it ... we already fail to be smart about things that are much simpler and more visible.
More interestingly, this may be what all CPU behavior looks like in 10 years, because if Intel has to resort to this kind of design now, why would hat change any time soon? Instead of worrying about primarily keeping the execution units full, people trying to write fast code may be primarily concerned with keeping them NOT full so that the chip doesn’t slow down. Which sounds crazy and hard to deal with.
- VHRanger 8y agoFwiw, autovectorizers tend to be pretty conservative about it. So to use cutting edge instructions you generally have to hand code them (either in intrinsics like Lemire did there or in asm)
- BeeOnRope 8y agoEspecially for FP instructions, where compilers are heavily restricted by the standard and IEEE754 semantics. Vectorization often changes the order of operations and since FP math is generally not associative. For integer operations, auto-vectorization is more prevalent since everything can be reordered more freely. clang especially auto-vectorizes a ton of stuff even at -O2.
- int_19h 8y agoBut that's precisely why most language standards don't require strict IEEE754 semantics. And why people mostly compile with -ffast-math or equivalent when they do.
- gameswithgo 8y agoYou won't get floating point simd of any kind without the ffastmath flag on gcc, msvc, or llvm or probably anything.