3 ms·
Only for small copies (due to static overhead/no branch prediction in microcode). For large buffers, rep/movs has been a win since ivybridge once your buffers a
by stephencanon 9y ago
Only for small copies (due to static overhead/no branch prediction in microcode). For large buffers, rep/movs has been a win since ivybridge once your buffers are too large for L2. A big part of this is that the stores used by rep/movs get to do a dataless read-for-ownership, so they actually move 1/3 less data around than any other implementation when they miss L2.
- vardump 9y ago> get to do a dataless read-for-ownership, so they actually move 1/3 less data around than any other implementation when they miss L2. Can't you achieve same using cache line sized non-temporal stores?
- stephencanon 9y agoThere are no cacheline-size store instructions pre AVX-512 (on Ivybridge, the widest store is 32B, and even that cracks to two 16B store uops; it's a real 32B store on Haswell+). Also the NT stores suffer from a bunch of other hazards that rep/movs avoids.
- gpderetta 9y agoNon temporal stores shouldn't go to the cache at all though. They go to write combining buffers instead.
- stephencanon 9y agoShouldn't, but do. They RFO into the LLC.
- arghwhat 9y agoAnother obvious win is that you do not trash "user-facing" registers with rep mov, like you do with a multi-xmm-register dance. I'm pro rep mov, but an XMM duffs device just won over rep mov where I tested. It was years ago, however, so I do not remember if I tried to run above L2 and L3. It was related to a compiler optimization debate for alternate memcpy/memmove implementations...