Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 11, 2020 6:54 pm wrote:
> Jörn Engel (joern.delete@this.purestorage.com) on July 11, 2020 4:45 pm wrote:
> >
> > While I mostly agree, there are a handful of exceptions. One is memcpy/memset where doing a full cacheline
> > at once is useful.
>
> That has nothing to do with AVX512.
>
> In fact, AVX512 is completely the wrong model for it.
>
> You can do it better and more artfully with "rep movs/stos".
>
> So I do not disagree AT ALL about memcpy/memset being hugely important. Quite the reverse.
>
> But I disagree violently about that being an argument for AVX512. Quite the reverse. The absolute
> last thing you want to do is have your (very common) memcpy/memset cause that huge unit to be powered
> on, and have all the headaches that goes with exposing all that intermediate internal state.

Depending on how you use memcpy, rep movs is quite horrible. I tested it and performance tanked, it was 2x or 3x slower, something like that. I care about doing many mostly-short copies and the current implementation of rep movs has a fairly high constant overhead per invocation.

If you only care about 1k or larger, rep movs is wonderful, I agree. If you have a small sprinkling of copies in relatively cold code, the size advantage is probably more important than the constant overhead. So sure, it is the right solution for most of the code you care about. I just wish the implementation would improve to the point where I could use it as well.

Btw, I also tested AVX512 and doing 64B copies instead of 32B copies was no improvement. So again, the interface doesn't matter much if the implementation is poor.