3 ms·

Well, akhchtually! rep mov is pretty fast these days (on Ivy Bridge onwards). On the other hand XMM registers are pretty old, we have YMM and ZMM now.

by guest_may_2017 9y ago

arghwhat 9y ago
When I tried on an Ivy Bridge laptop-class processor a few years back, move over XMM utilizing a handful of registers was still significantly faster than rep mov. It would make sense for Intel to improve it, though. But my point was more that you need to know what it does to know what you compare. That the "fast way" changes over time makes it even more important.
- 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 ago
      There 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 ago
        Non temporal stores shouldn't go to the cache at all though. They go to write combining buffers instead.
        stephencanon 9y ago
        Shouldn't, but do. They RFO into the LLC.
  - arghwhat 9y ago
    Another 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...

Well, akhchtually! rep mov is pretty fast these days (on Ivy Bridge onwards). On the other hand XMM registers are pretty old, we have YMM and ZMM now.

arghwhat 9y ago

When I tried on an Ivy Bridge laptop-class processor a few years back, move over XMM utilizing a handful of registers was still significantly faster than rep mov. It would make sense for Intel to improve it, though. But my point was more that you need to know what it does to know what you compare. That the "fast way" changes over time makes it even more important.

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 ago
    There 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 ago
      Non temporal stores shouldn't go to the cache at all though. They go to write combining buffers instead.
      - stephencanon 9y ago
        Shouldn't, but do. They RFO into the LLC.
- arghwhat 9y ago
  Another 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...