This is the mail archive of the 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: time unit in bench-skeleton

On Tue, Jun 27, 2017 at 9:49 PM, Siddhesh Poyarekar <> 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?

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