3 ms·
Staring is not enough, you need to benchmark. You might be surprised. The results are often counterintuitive, because it's hard for a human to account for how
by m0zg 8y ago
Staring is not enough, you need to benchmark. You might be surprised.
The results are often counterintuitive, because it's hard for a human to account for how the program _actually_ gets executed, which instructions go in which order, port utilization, data dependencies, CPU bugs, effects of alignment (or, often, lack thereof on Intel CPUs), micro-op caching, etc etc. For all you know GCC deliberately avoided the use of AVX512 registers because AVX512 causes the CPU to throttle the clock.
I've also found that ye olde -O2 flag recommendation which says -O3 is likely to be slower in practice because it produces bulkier machine code, nearly never holds up anymore.
That said, I concede that autovectorization is not perfect. I can almost always beat it if I really want to, sometimes by quite a margin. But what you're proposing is unlikely to help matters, especially for smaller inputs that you're concerned about.
- CoolGuySteve 8y agoI have benchmarked similar code extensively, this is a toy version of a FIX checksum. It's not "counterintuitive", it's just broken, especially for infrequently executed code where the instruction fetch stalls will kill your latency. You are welcomed to load up the godbolt example and try and create better assembly using O2 or whatever else you can think of. You can build the code on your machine and benchmark it too. But at the end of the day, the compiler output sucks. It's clearly optimized for synthetic benchmarks that chug through large datasets using a tiny amount of code that can fit in L1 cache even after the compiler blows up its footprint. But my point is that these large datasets with tiny processing kernels (like a video codec for example) are much better suited to different kinds of processors.