This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH] sysdeps/arm/armv7/multiarch/memcpy_impl.S: Improve performance.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: OndÅej BÃlka <neleai at seznam dot cz>, Will Newton <will dot newton at linaro dot org>, "libc-ports at sourceware dot org" <libc-ports at sourceware dot org>, Patch Tracking <patches at linaro dot org>
- Date: Wed, 04 Sep 2013 11:30:30 -0400
- Subject: Re: [PATCH] sysdeps/arm/armv7/multiarch/memcpy_impl.S: Improve performance.
- Authentication-results: sourceware.org; auth=none
- References: <CANu=DmiBHoymFKTvaW_VsdhWZEYwkfViz1tTeRgj7H80f0FntA at mail dot gmail dot com> <5220D30B dot 9080306 at redhat dot com> <CANu=DmiXLL9v1Z1KS0sBOs-pL8csEUGc9YE829_-tidKd-GruQ at mail dot gmail dot com> <5220F1F0 dot 80501 at redhat dot com> <CANu=DmhA9QvSe6RS72Db2P=yyjC72fsE8d4QZKHEcNiwqxNMvw at mail dot gmail dot com> <52260BD0 dot 6090805 at redhat dot com> <20130903173710 dot GA2028 at domone dot kolej dot mff dot cuni dot cz> <522621E2 dot 6020903 at redhat dot com> <20130903185721 dot GA3876 at domone dot kolej dot mff dot cuni dot cz> <5226354D dot 8000006 at redhat dot com> <20130904073008 dot GA4306 at spoyarek dot pnq dot redhat dot com>
On 09/04/2013 03:30 AM, Siddhesh Poyarekar wrote:
> On Tue, Sep 03, 2013 at 03:15:25PM -0400, Carlos O'Donell wrote:
>> I agree. The eventual goal of the project is to have some kind of
>> whole system benchmarking that allows users to feed in their profiles
>> and allow us as developers to see what users are doing with our library.
>>
>> Just like CPU designers feed in a whole distribution of applications
>> and look at the probability of instruction selection and tweak instruction
>> to microcode mappings.
>>
>> I am willing to accept a certain error in the process as long as I know
>> we are headed in the right direction. If we all disagree about the
>> direction we are going in then we should talk about it.
>>
>> I see:
>>
>> microbenchmarks -> whole system benchmarks -> profile driven optimizations
>
> I've mentioned this before - microbenchmarks are not a way to whole
> system benchmarks in that they don't replace system benchmarks. We
> need to work on both in parallel because both have different goals.
Sorry, my ASCII graph was misleading, and I agree with you.
What I meant to say is that we need to walk before we run.
Creating a microbenchmark framework will give us the tools
we need to move on to whole system benchmarks and eventually
to profile driven optimizations. We will continue to do all
3 of these activities once we reach the end of that logical
progression.
Cheers,
Carlos.