mailing list of musl libc
 help / color / Atom feed
* [musl] memcpy/memcmp optimizations and possible alternatives
@ 2020-05-16  3:07 Srinivasan J
  2020-05-16  3:40 ` Rich Felker
  0 siblings, 1 reply; 2+ messages in thread
From: Srinivasan J @ 2020-05-16  3:07 UTC (permalink / raw)
  To: musl

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [musl] memcpy/memcmp optimizations and possible alternatives
  2020-05-16  3:07 [musl] memcpy/memcmp optimizations and possible alternatives Srinivasan J
@ 2020-05-16  3:40 ` Rich Felker
  0 siblings, 0 replies; 2+ messages in thread
From: Rich Felker @ 2020-05-16  3:40 UTC (permalink / raw)
  To: musl; +Cc: Srinivasan J

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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-16  3:07 [musl] memcpy/memcmp optimizations and possible alternatives Srinivasan J
2020-05-16  3:40 ` Rich Felker

mailing list of musl libc

Archives are clonable: git clone --mirror http://inbox.vuxu.org/musl

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git