[musl] memcpy/memcmp optimizations and possible alternatives

[musl] memcpy/memcmp optimizations and possible alternatives

[Srinivasan J]

Hi,
   I see that the musl-libc implementations of mem* functions does not
use AVX/SSE4 instructions. Please let me know if there is a plan to
support these or if there is a recommended way to use optimized
versions of mem* functions when running memory intensive applications
with musl-libc. The application is being run in alpine linux.

Thanks,
Srini

Re: [musl] memcpy/memcmp optimizations and possible alternatives

[Rich Felker]

On Sat, May 16, 2020 at 08:37:34AM +0530, Srinivasan J wrote:
> Hi,
>    I see that the musl-libc implementations of mem* functions does not
> use AVX/SSE4 instructions. Please let me know if there is a plan to
> support these or if there is a recommended way to use optimized
> versions of mem* functions when running memory intensive applications
> with musl-libc. The application is being run in alpine linux.

You can safely replace memcpy/memcmp with another implementation just
by linking it in your program, as long as it matches the contract of
the standard function and GCC's additional requirements on the
function.

On modern x86, "rep mov" is, or at least until recently was, supposed
to be the fastest way to memcpy. But AMD and Intel like to keep making
regressions in this area so it's possible it's not true anymore. I
haven't kept up with it the past few years. At least some of the
possible alternatives have properties that might make them slower
depending on use or even unsafe with respect to weakly ordered memory
operations.

It's possible that if there are reliably faster approaches, we'll
integrate them at some point. Probably not with any runtime selection,
although it's inexpensive to do the selection in a code path only used
for large n, so it might be ok.

Note that our memcmp right now is really bad, and should be optimized.