public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Ramana Radhakrishnan <ramana.gcc@googlemail.com>
Cc: Wilco Dijkstra <Wilco.Dijkstra@arm.com>,
	Andrew Pinski <pinskia@gmail.com>,
	Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
	"Ellcey, Steve" <Steve.Ellcey@cavium.com>,
	libc-alpha <libc-alpha@sourceware.org>, nd <nd@arm.com>
Subject: Re: Ping: [Patch] aarch64: Thunderx specific memcpy and memmove
Date: Fri, 26 May 2017 05:34:00 -0000	[thread overview]
Message-ID: <7507f346-53ab-5c3a-a39d-c5ee839159fa@gotplt.org> (raw)
In-Reply-To: <CAJA7tRbBBLf6DbtPk3i9tuotw-B7icf0UTXtN5=gcTogX-o8jA@mail.gmail.com>

On Friday 26 May 2017 02:34 AM, Ramana Radhakrishnan wrote:
> SVE in the ARM world is architectural and not micro-architectural in the context
> of this discussion :) .

Yes, I did not think of SVE as a micro-architecture detail.  I used SVE
as an example to show that multiarch =/=> micro-architectures.

> The difference in the ARM world compared to the x86 world is the number
> of micro-architectures that target the same architectural baseline.
> Pushing in a memcpy
> for every single micro-architecture out there will make the library a
> maintenance
> nightmare !

Nor am I arguing that micro-architectures ==> multiarch.  My comments
have only been pointing out that the IFUNC cost for multiarch is here to
stay and there will likely never be consensus to drop it given the
innovations happening in the ARM server space.

> And we also need to see some numbers which compare the relative performance
> of the routines being put in compared to the generic memcpy otherwise things
> will not improve.  Atleast something like this routine is X % better than the
> generic memcpy.

Yes, and I understand Steve had pointed out the benefits of his
implementation in the original post.  If it turns out that the
implementation is optimal for the general case, by all means merge it
with the generic one but that's not a reason to drop multiarch.

Siddhesh

  parent reply	other threads:[~2017-05-26  5:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-01 18:27 Steve Ellcey
2017-05-01 21:20 ` Wainer dos Santos Moschetta
2017-05-03 14:01 ` Szabolcs Nagy
2017-05-09  3:17   ` Siddhesh Poyarekar
2017-05-09 21:45     ` Steve Ellcey
2017-05-18 21:48       ` Steve Ellcey
2017-05-19  7:41       ` Siddhesh Poyarekar
     [not found]         ` <DM5PR07MB34662F805C1EDE45882B82F6F5F90@DM5PR07MB3466.namprd07.prod.outlook.com>
2017-05-24 17:04           ` Szabolcs Nagy
2017-05-25  6:42             ` Siddhesh Poyarekar
2017-05-25 16:28               ` Andrew Pinski
2017-05-25 16:43                 ` Ramana Radhakrishnan
2017-05-25 17:49                 ` Wilco Dijkstra
2017-05-25 19:26                   ` Siddhesh Poyarekar
2017-05-25 21:04                     ` Ramana Radhakrishnan
2017-05-25 21:12                       ` Florian Weimer
2017-05-26  5:42                         ` Siddhesh Poyarekar
2017-05-26  5:34                       ` Siddhesh Poyarekar [this message]
2017-05-26  5:38                         ` Andrew Pinski
2017-05-25 16:22             ` Steve Ellcey

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=7507f346-53ab-5c3a-a39d-c5ee839159fa@gotplt.org \
    --to=siddhesh@gotplt.org \
    --cc=Steve.Ellcey@cavium.com \
    --cc=Szabolcs.Nagy@arm.com \
    --cc=Wilco.Dijkstra@arm.com \
    --cc=libc-alpha@sourceware.org \
    --cc=nd@arm.com \
    --cc=pinskia@gmail.com \
    --cc=ramana.gcc@googlemail.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.
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).