From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: Noah Goldstein <goldstein.w.n@gmail.com>,
Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: "H.J. Lu" <hjl.tools@gmail.com>,
GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] elf: Replace memcmp with __memcmpeq for variable size
Date: Wed, 9 Feb 2022 01:42:26 +0000 [thread overview]
Message-ID: <AS8PR08MB65341786379B814BF5772571832E9@AS8PR08MB6534.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <CAFUsyfJwp=UzEQ2TPafCk=TxDY5f+r8+JGWWhASrjC-cDJG5Qw@mail.gmail.com>
Hi,
> I think the I-cache usage increase is only when '__memcmpeq' is
> partially implemented.
> In many applications 'memcmp' can be entirely replaced with
> '__memcmpeq' and '__memcmpeq'
> has a lower I-cache footprint than 'memcmp'. Although agree its best
> to get this into GCC.
Even in the best case, the savings are really marginal. On AArch64 it would
save about 56 bytes. For the most common sizes it will not make a difference
at all since caches work on whole cachelines.
To check performance I ran a __memcmpeq through the strstr benchmark
(since that stresses memcmp), and that only gave minor differences. So there
isn't a clear performance benefit either.
It gets worse for the other proposals, like resurrecting bzero. This was great in
the 80's and 90's when we had basic in-order cores without branch prediction
and every instruction avoided was a big win. But is trying to save one instruction
per memset call really a useful optimization on wide OoO cores?
Cheers,
Wilco
next prev parent reply other threads:[~2022-02-09 1:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 22:30 Wilco Dijkstra
2022-02-08 23:00 ` Adhemerval Zanella
2022-02-09 0:07 ` Noah Goldstein
2022-02-09 1:42 ` Wilco Dijkstra [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-02-06 21:09 H.J. Lu
2022-02-06 22:19 ` Florian Weimer
2022-02-07 0:20 ` H.J. Lu
2022-02-07 10:40 ` Florian Weimer
2022-02-07 13:13 ` H.J. Lu
2022-02-07 13:19 ` Florian Weimer
2022-02-07 13:27 ` H.J. Lu
2022-02-07 13:30 ` Adhemerval Zanella
2022-02-07 14:00 ` H.J. Lu
2022-02-07 20:35 ` Joseph Myers
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=AS8PR08MB65341786379B814BF5772571832E9@AS8PR08MB6534.eurprd08.prod.outlook.com \
--to=wilco.dijkstra@arm.com \
--cc=adhemerval.zanella@linaro.org \
--cc=goldstein.w.n@gmail.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
/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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).