This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Faster strlen


On Tue, Oct 9, 2012 at 9:51 AM, Andi Kleen <andi@firstfloor.org> wrote:
> OndÅej BÃlka <neleai@seznam.cz> writes:
>>
>> I also benchmarked atom and added variant which is identical to
>> strlen-sse2-pminub except bsf is replaced by table lookup.
>
> Is your micro benchmark just a tight loop or does it fill the caches?
>
> I have doubts that table lookups are a good idea if it blows away
> the working set in L1 for the application.
>
> Microbenchmarks that do not use caches much can be very misleading
> here. Even if it's slightly slower not doing table lookups
> is usually preferred for functions like this, simply because it lessens
> the impact on the caches.
>
> I would recommend to measure what happens both if the microbenchmark
> stresses data cache and icache. Otherwise you risk winning
> benchmarks, but making real apps slower.

Andi,

Thanks for your feedback. We definitely need as many reviewers and
developers as possible for these types of changes. I appreciate you
taking the time to look at this.

In general glibc lacks performance criteria for accepting patches that
change core functions.

Ondrej and others have been working hard to try remedy this by
creating a set of benchmarks that we can use to measure the impact of
one patch or another, and documenting why patches were accepted and
what the performance criteria was for their inclusion.

You can see some of this work here:
http://sourceware.org/glibc/wiki/benchmarking/benchmarks

Help is welcome.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]