I don't know what's the current status quo, but most of the time after 80286/80386, "rep stos" and "rep movs" has been significantly slower than just (loading and) storing data in an unrolled loop. This limits usefulness just to very short spans or when code size is most important. But most short spans are also predictable (static), so compilers can often just generate an instruction or two to do so (like xor eax, eax / mov <target>, eax).
Currently the fastest way to memset large chunks of memory is probably to use SSE or AVX. I'd guess this is what gets generated if compiler target arch allows.
With SSE/AVX you also have an option to use non-temporal moves to avoid polluting caches. This might have a negative impact on any memset micro-benchmark [1], but significantly help any concurrently executing memory bound CPU cores.
Properly aligned (cache line 64-byte boundary) you might be able to avoid read-for-ownership as well, further reducing memory bus traffic.
So most use of rep-prefix might be pointless, unless you can accept the performance hit.
[1]: Just like micro-benchmarking any other resource constrained operation. Micro-benchmarks can give you very wrong idea of what is best for the system as a whole.
Currently the fastest way to memset large chunks of memory is probably to use SSE or AVX. I'd guess this is what gets generated if compiler target arch allows.
With SSE/AVX you also have an option to use non-temporal moves to avoid polluting caches. This might have a negative impact on any memset micro-benchmark [1], but significantly help any concurrently executing memory bound CPU cores.
Properly aligned (cache line 64-byte boundary) you might be able to avoid read-for-ownership as well, further reducing memory bus traffic.
So most use of rep-prefix might be pointless, unless you can accept the performance hit.
[1]: Just like micro-benchmarking any other resource constrained operation. Micro-benchmarks can give you very wrong idea of what is best for the system as a whole.