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: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: "vm dot rod25 at gmail dot com" <vm dot rod25 at gmail 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 14:55:22 +0000
- Subject: Re: [PATCH 1/2] benchtests: Memory walking benchmark for memcpy
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Wilco dot Dijkstra at arm dot com;
- Nodisclaimer: True
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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.
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?
Wilco