public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: "Ryan S. Arnold" <ryan.arnold@gmail.com>
To: "Carlos O'Donell" <carlos@redhat.com>
Cc: "Will Newton" <will.newton@linaro.org>,
	"libc-ports@sourceware.org" <libc-ports@sourceware.org>,
	"Patch Tracking" <patches@linaro.org>,
	"Ondřej Bílka" <neleai@seznam.cz>,
	"Siddhesh Poyarekar" <siddhesh@redhat.com>
Subject: Re: [PATCH] sysdeps/arm/armv7/multiarch/memcpy_impl.S: Improve performance.
Date: Tue, 03 Sep 2013 19:31:00 -0000	[thread overview]
Message-ID: <CAAKybw99YcSoyU58w2iqHGRTQpajAtKX6JZp=r57bT37fjvQ2Q@mail.gmail.com> (raw)
In-Reply-To: <52260BD0.6090805@redhat.com>

On Tue, Sep 3, 2013 at 11:18 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> We have one, it's the glibc microbenchmark, and we want to expand it,
> otherwise when ACME comes with their patch for ARM and breaks performance
> for targets that Linaro cares about I have no way to reject the patch
> objectively :-)

Can you be objective in analyzing performance when two different
people have differing opinions on what performance preconditions
should be coded against?

There are some cases that are obvious.. we know that from pipeline
analysis that certain instruction sequences can hinder performance.
That is objective and can be measured by a benchmark, but saying that
a particular change penalizes X sized copies but helps Y sized copies
when there are no published performance preconditions isn't.  It's a
difference in opinion of what's important.

PowerPC has had the luxury of not having their performance
pre-conditions contested.  PowerPC string performance is optimized
based upon customer data-set analysis.  So PowerPC's preconditions are
pretty concrete...  Optimize for aligned data in excess of 128-bytes
(I believe).

> You need to statistically analyze the numbers, assign weights to ranges,
> and come up with some kind of number that evaluates the results based
> on *some* formula. That is the only way we are going to keep moving
> performance forward (against some kind of criteria).

This sounds like establishing preconditions (what types of data will
be optimized for).

Unless technology evolves that you can statistically analyze data in
real time and adjust the implementation based on what you find (an
implementation with a different set of preconditions) to account for
this you're going to end up with a lot of in-fighting over
performance.

I've run into situations where I recommended that a customer code
their own string function implementation because they continually
encountered unaligned-data when copying-by-value in C++ functions and
PowerPC's string function implementations penalized unaligned copies
in preference for aligned copies.

Ryan

  parent reply	other threads:[~2013-09-03 19:31 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-12  7:55 Will Newton
2013-08-27  7:46 ` Will Newton
2013-08-30 17:14   ` Carlos O'Donell
2013-08-30 18:48     ` Will Newton
2013-08-30 19:26       ` Carlos O'Donell
2013-09-02 14:18         ` Will Newton
2013-09-03 16:14           ` Carlos O'Donell
     [not found]         ` <CANu=DmhA9QvSe6RS72Db2P=yyjC72fsE8d4QZKHEcNiwqxNMvw@mail.gmail.com>
2013-09-02 14:18           ` benchmark improvements (Was: Re: [PATCH] sysdeps/arm/armv7/multiarch/memcpy_impl.S: Improve performance.) Siddhesh Poyarekar
2013-09-03 13:46             ` Will Newton
2013-09-03 17:48               ` Ondřej Bílka
2013-09-02 19:57           ` [PATCH] sysdeps/arm/armv7/multiarch/memcpy_impl.S: Improve performance Ondřej Bílka
2013-09-03 16:18           ` Carlos O'Donell
2013-09-03 17:37             ` Ondřej Bílka
2013-09-03 17:52               ` Carlos O'Donell
2013-09-03 18:57                 ` Ondřej Bílka
2013-09-03 19:15                   ` Carlos O'Donell
2013-09-04  7:27                     ` Siddhesh Poyarekar
2013-09-04 11:03                       ` Ondřej Bílka
2013-09-04 11:43                         ` Siddhesh Poyarekar
2013-09-04 17:37                         ` Ryan S. Arnold
2013-09-05  8:04                           ` Ondřej Bílka
2013-09-04 15:30                       ` Carlos O'Donell
2013-09-04 17:35                       ` Ryan S. Arnold
2013-09-05 11:07                         ` Ondřej Bílka
2013-09-05 11:54                         ` Joseph S. Myers
2013-09-03 19:34               ` Ryan S. Arnold
2013-09-07 11:55                 ` Ondřej Bílka
2013-09-03 19:31             ` Ryan S. Arnold [this message]
2013-09-03 19:54               ` Carlos O'Donell
2013-09-03 20:56                 ` Ryan S. Arnold
2013-09-03 23:29                   ` Ondřej Bílka
2013-09-03 23:31                   ` Carlos O'Donell
2013-09-03 22:27               ` Ondřej Bílka
2013-08-29 23:58 ` Joseph S. Myers
2013-08-30 14:56   ` Will Newton
2013-08-30 15:18     ` Joseph S. Myers
2013-08-30 18:46       ` Will Newton

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='CAAKybw99YcSoyU58w2iqHGRTQpajAtKX6JZp=r57bT37fjvQ2Q@mail.gmail.com' \
    --to=ryan.arnold@gmail.com \
    --cc=carlos@redhat.com \
    --cc=libc-ports@sourceware.org \
    --cc=neleai@seznam.cz \
    --cc=patches@linaro.org \
    --cc=siddhesh@redhat.com \
    --cc=will.newton@linaro.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).