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 1/2] benchtests: Memory walking benchmark for memcpy


On Thu, Oct 5, 2017 at 9:55 AM, Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
> Victor Rodriguez wrote:
>
>> Quick question , do you think it might be good idea to add this test
>> into the prhonix glibc bench :
>>
>> https://openbenchmarking.org/test/pts/glibc-bench
>> https://openbenchmarking.org/innhold/cac2836cd5dbb8ae279f8a5e7b0896272e82dc76
>>
>> If so, let me know so I can work on add it
>
> Currently this seems to run:
>
> ffsll
> ffs
> pthread_once
> ffsll
> tanh
> sqrt
>
> So half(!) of the tests are find first set bit, which is not frequently used. When used it is inlined as a builtin so the performance of the GLIBC call (which is unoptimized for all but a few targets) doesn't matter at all. For some targets it ends up as a single instruction, so it really measures the overhead of the plt call... Sqrt is similar, it's just a plt call + sqrt throughput comparison. I'm not sure about the usefulness of pthread_once.
>
> tanh is reasonable - however I would suggest changing to the powf benchmark instead as GLIBC has an optimized generic implementation and now runs an actual trace (instead of repeating the same input again and again). Running that against older GLIBCs or other C libraries would show great gains!
>
> Overall I think the idea of running GLIBC benchmarks elsewhere is great, and improving it and adding memcpy benchmarks would be useful. But like with all benchmarking it's important to understand what you're trying to measure and why in order to get meaningful results. So I think the first step is to decide what the goal of this benchmark is.
>
Yes, you are right, we need to do a deep analysis of what we want to
have on the glibc bench

I agree with all the feedback you provide. I am going to start a new
thread specific for Glibc bench

Now that the GLIBC bench is getting more attraction, is time to improve it

> For example, is it tracking performance of frequently used performance critical functions across GLIBC versions or other C libraries? Or about comparing target-specific optimizations of rarely used functions?
>
The idea is to compare the performance of critical functions across
GLIBC functions

> Wilco

Thanks a lot for the interest and feedback


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