2 ms·
> SIMD operations are contant time, since the whole vector needs to be computed Is that actually guaranteed? Having to do the whole vector doesn't necessarily
by viraptor 2y ago
> SIMD operations are contant time, since the whole vector needs to be computed
Is that actually guaranteed? Having to do the whole vector doesn't necessarily mean the time can't vary for different values for complex operations. (like division)
I can't find the details, but https://gleissen.github.io/papers/iodine.pdf https://gleissen.github.io/papers/iodine.pdf at least mentions "Dually, if timing variability is unavoidable, e.g.,
in SIMD or floating-point units, making this variability
explicit can better inform..." so it sounds like simd is at least situation specific here.
- manwe150 2y agoI wonder if you could have a compiler that intentionally pads every instruction to use a vector register pair of <value, slow-const>, so that every value gets paired with whatever constant or other expression will cause the slowest execution of that vector instruction and with the maximum latency chain. Otherwise, it does look like the VDIV instructions can have variable latencies based on the data itself (and not just spectre-like speculation issues on the memory access patterns). From https://uops.info/table.html https://uops.info/table.html
- Sesse__ 2y agoYou don't have any guarantee that the SIMD operations are actually done in parallel (which is of of the assumptions needed for “the latency matches that of the slowest element”). E.g., I believe VPGATHERDD is microcoded (and serial) on some CPUs, NEON (128-bit) is designed to be efficiently implementable by running a 64-bit ALU twice, AVX2 and AVX512 double-pumped on some (many) CPUs likewise…
- hovav 2y agoIt's not guaranteed. See section 7 of https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-kohlbrenner.pdf https://www.usenix.org/system/files/conference/usenixsecurit...