This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: time unit in bench-skeleton
- From: Siddhesh Poyarekar <siddhesh at gotplt dot org>
- To: Carlos O'Donell <carlos at redhat dot com>, Victor Rodriguez <vm dot rod25 at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 28 Jun 2017 10:19:42 +0530
- Subject: Re: time unit in bench-skeleton
- Authentication-results: sourceware.org; auth=none
- References: <CAK5mtey=C09DO0VTy0kK5vFNA5dasY4kdu6xc=rs5pOhsqy0rw@mail.gmail.com> <5282c9e5-da80-76f9-3542-051929a9a73f@redhat.com>
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