4 ms·

> However I noticed that when there were many load/store operations to do, there was no particular gain. See for example this code: You may be running out of c

by qb45 10y ago

> However I noticed that when there were many load/store operations to do, there was no particular gain. See for example this code: You may be running out of cache/memory bandwidth, compare your throughput with numbers from benchmarks or "Software Optimization Manual" of your CPU. If you are on Linux, try perf stat -d ./whatever which reports, among other things, the rate of cache and memory hits, obtained from hardware "performance counters". > _mm256_loadu_ps Some years ago and with SSE, unaligned was slower than aligned. On some chips only if the address happened to really be unaligned, on others in every case. Not sure how it is with AVX.

zbjornson 10y ago
On recent processors (last few years), as long as you're not crossing a cache line, unaligned is essentially the same as aligned in terms of performance.
- 737774 10y ago
  Oh wow - how is that achieved? I've spent my career in mobile and didn't know this was true on desktop
  - stephencanon 10y ago
    This is true on modern mobile CPUs, too. ARMv8 doesn't even have explicit aligned vector loads.
- antirez 10y ago
  Oh! That's super interesting, so I know there is no point in trying to improve the alignment too much. I'll try anyway if I can make the whole operation a linear scan but if there is no big penalty, to add padding among weights looks like a bad idea.
  - qb45 10y ago
    > That's super interesting, so I know there is no point in trying to improve the alignment too much. Typical x86 cache line size is 64B, AVX registers are 32B. When your o pointer isn't 32B-aligned, you are loading across cache line boundary every second time. If nkurz is right and this loop can run 1 iteration per cycle, misalignemnt probably slows it down to 2i/3c. Benchmark this loop if you want to know. Of course it only matters if the array is still in L1, maybe L2 (?). edit: Not exactly 2i/3c, see http://www.agner.org/optimize/blog/read.php?i=415#423 http://www.agner.org/optimize/blog/read.php?i=415#423

by qb45 10y ago

zbjornson 10y ago

On recent processors (last few years), as long as you're not crossing a cache line, unaligned is essentially the same as aligned in terms of performance.

737774 10y ago
Oh wow - how is that achieved? I've spent my career in mobile and didn't know this was true on desktop
- stephencanon 10y ago
  This is true on modern mobile CPUs, too. ARMv8 doesn't even have explicit aligned vector loads.
antirez 10y ago
Oh! That's super interesting, so I know there is no point in trying to improve the alignment too much. I'll try anyway if I can make the whole operation a linear scan but if there is no big penalty, to add padding among weights looks like a bad idea.
- qb45 10y ago
  > That's super interesting, so I know there is no point in trying to improve the alignment too much. Typical x86 cache line size is 64B, AVX registers are 32B. When your o pointer isn't 32B-aligned, you are loading across cache line boundary every second time. If nkurz is right and this loop can run 1 iteration per cycle, misalignemnt probably slows it down to 2i/3c. Benchmark this loop if you want to know. Of course it only matters if the array is still in L1, maybe L2 (?). edit: Not exactly 2i/3c, see http://www.agner.org/optimize/blog/read.php?i=415#423 http://www.agner.org/optimize/blog/read.php?i=415#423