mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Cc: Srinivasan J <srinidpdk@gmail.com>
Subject: Re: [musl] memcpy/memcmp optimizations and possible alternatives
Date: Fri, 15 May 2020 23:40:19 -0400	[thread overview]
Message-ID: <20200516034016.GP21576@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAEbeQ+orK1naVD6+aC2=LijWsHxEL7Vmz1msorG7-=-Tv1Mj6Q@mail.gmail.com>

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.

      reply	other threads:[~2020-05-16  3:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-16  3:07 Srinivasan J
2020-05-16  3:40 ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200516034016.GP21576@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    --cc=srinidpdk@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).