Doug S (foo.delete@this.bar.bar) on May 23, 2017 2:35 pm wrote:
>
> Given how large of a footprint memory copies/zeroing/setting has on many profiles, perhaps we need
> special instructions designed for the task. With multiple threads of execution becoming common,
> perhaps having a long (in terms of time for instruction to complete) memory copy/set instruction
> occupying a thread wouldn't be a bad thing, so long as it is interruptible and restartable.

I'm a huge fan of "rep movsb".

It's actually a great interface, in that it's exactly that interruptible and restartable, with minimal (literally: source, destination and count) register state. No stupid big data registers to hold the data. No stupid alignment issues or worries about the cacheline size.

Yes, that silly DF bit is annoying and useless, and writing optimized memory copy code in microcode is not trivial when you have to take all the possible aliasing issues into account. And yes, you technically have stricter semantic guarantees than "memcpy()", since you do have to act as if you are copying one byte at a time in a particular direction, so that does limit you a tiny bit.

So it's not a perfect interface, but it really does get fairly close. Fixed registers might be something that raises peoples hackles, but think of it as just a calling convention, and everybody is ok with that.

I will take a better implementation of "rep movsb" and "rep stosb" any day over some stupid wide vector unit thing. It avoids all the edge cases, and it avoids the whole "save/restore pointless register state" crap too.

And Intel actually does do fairly well. "rep movs" is often - but not always - the best memory copy implementation (with "rep stosb" being often the best memory clearing).

Obviously, if you have a compile-time size constant where the size is small enough, you are much better off implementing memcpy() as a fixed set of loads and stores. That goes without saying. But if you have a variable sized copy, the overhead of doing some microcode for it shouldn't be any worse than the size tests.

Of course, a lot of benchmarks are bad, and assume that (a) I$ doesn't matter (so the benchmark just does a memcpy over and over again and even insane complex routines are basically "free") and (b) often tests particular sizes over and over again so that the size tests look like they are free because they predict well.

So "rep movsb" seldom beats hand-tuned things when that happens. But it actually does fairly well in general, and often is the best choice. But there have historically been a few cases where it falls down badly, so..

Most of the rest of the "rep" instructions aren't nearly as useful. "strnlen()" and friends do show up in profiles and you could imagine a good "rep scasb" too, but it is nowhere near as important as memcpy/memset so it's probably not worth it.

Linus