This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: time unit in bench-skeleton
- From: Victor Rodriguez <vm dot rod25 at gmail dot com>
- To: Siddhesh Poyarekar <siddhesh at gotplt dot org>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 28 Jun 2017 08:03:49 -0700
- 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> <a1895cb0-156f-208d-a54b-3bdc2e81e75f@gotplt.org>
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?