From: "Ondřej Bílka" <email@example.com>
To: "Ryan S. Arnold" <firstname.lastname@example.org>
Cc: Carlos O'Donell <email@example.com>,
Will Newton <firstname.lastname@example.org>,
Patch Tracking <email@example.com>,
Siddhesh Poyarekar <firstname.lastname@example.org>
Subject: Re: [PATCH] sysdeps/arm/armv7/multiarch/memcpy_impl.S: Improve performance.
Date: Tue, 03 Sep 2013 22:27:00 -0000 [thread overview]
Message-ID: <20130903222715.GA7148@domone.kolej.mff.cuni.cz> (raw)
On Tue, Sep 03, 2013 at 02:31:14PM -0500, Ryan S. Arnold wrote:
> On Tue, Sep 3, 2013 at 11:18 AM, Carlos O'Donell <email@example.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?
I fear more situations like when google and facebook will send their
implementation which saves each milion dollars in energy bill over others
> > 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
Technology is there at least for x64, its political problem.
You do not need real time analysis most of time. When user accepts
possibility performance could be worse by constant factor then profiling
becomes easier. We could rely on data from previous runs of program
First step would be to replace ifunc selection by first running
benchmarks on processor and then creating hash table with numbers of
fastest implementation and selection will be done by this lookup.
My profiler could(modulo externalities) for each program measure
which implementation is fastest on given processor.
Then AFAIR appending data to elf is legal so we could append hash table
with program specific numbers to binary.
A ifunc resolver will first look to end of binary if there is ifunc table.
This could be implemented that worst that can happen for false positive
is selecting slow implementation. If there is entry for current processor it
will use it, otherwise it will look to table at end of libc.so and
repeat this step and if it was not found it will use default implementation.
This is doable, problems is motivate somebody to do profiling. My
approach tries to it possible for programmers (write testing, run it at
different machines and assemble), distributions (find enough users that
will agree to have sometimes turned profiling on and sending results.)
or end users who could turn profiling on to learn their patterns.
next prev parent reply other threads:[~2013-09-03 22:27 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
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 [this message]
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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).