This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] benchtests: Memory walking benchmark for memcpy
- From: Victor Rodriguez <vm dot rod25 at gmail dot com>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, "siddhesh at sourceware dot org" <siddhesh at sourceware dot org>, nd <nd at arm dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 5 Oct 2017 16:39:11 -0500
- Subject: Re: [PATCH 1/2] benchtests: Memory walking benchmark for memcpy
- Authentication-results: sourceware.org; auth=none
- References: <DB6PR0801MB205310A8930E421C5AF63F6B83700@DB6PR0801MB2053.eurprd08.prod.outlook.com>
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