Re: time unit in bench-skeleton

[Carlos O'Donell <carlos at redhat dot com>]

On 06/28/2017 11:03 AM, Victor Rodriguez wrote:
> On Tue, Jun 27, 2017 at 9:49 PM, Siddhesh Poyarekar <siddhesh@gotplt.org> wrote:
>> On Wednesday 28 June 2017 09:38 AM, Carlos O'Donell wrote:
>>>>  42 /* Measure the resolution of the clock so we can scale the number of
>>>>  43    benchmark iterations by this value.  */
>>>>  44 # define TIMING_INIT(res) \
>>>>  45 ({                                        \
>>>>  46   struct timespec start;                              \
>>>>  47   clock_getres (CLOCK_PROCESS_CPUTIME_ID, &start);                \
>>>>  48   (res) = start.tv_nsec;                          \
>>>>  49 })
>>>>
>>>> is in nanoseconds right?
>>>
>>> Correct. This is the resolution in nanoseconds of the clock source.
>>
>> Almost.  The clock_* API does this in nanoseconds, but architectures
>> that have clock source instructions support in benchtests (x86 for
>> example) may use the low level instructions directly and their
>> granularity may be different from a nanosecond.  A safer term to use
>> there would be clock ticks.  If you want to always use CLOCK_GETTIME (to
>> compare between architectures for example), call the benchmark using
>> 'make USE_CLOCK_GETTIME=1 bench'.
>>
>> Siddhesh
> 
> Thanks a lot, one more question, I was checking the src of the tests
> and as far as i understand the benchmarks are running against the
> installed Glibc right ? not the recently compiled. Am I right?
 
The microbenchmarks should always be compiled and run against the 
recently compiled glibc.

The point is to test your changes in the tree to see if they are
a benefit or not.

In Fedora we ship the compiled microbenchmarks with glibc as an
additional package. 

e.g. dnf search glibc-benchtests
glibc-benchtests.x86_64 : Benchmarking binaries and scripts for glibc

You can install these and run the microbenchmarks *again* on your
own system and against the installed glibc.

-- 
Cheers,
Carlos.