[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200516034016.GP21576@brightrain.aerifal.cx>
Date: Fri, 15 May 2020 23:40:19 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Cc: Srinivasan J <srinidpdk@...il.com>
Subject: Re: memcpy/memcmp optimizations and possible alternatives
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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
