This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: time unit in bench-skeleton
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Victor Rodriguez <vm dot rod25 at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 28 Jun 2017 00:08:23 -0400
- Subject: Re: time unit in bench-skeleton
- Authentication-results: sourceware.org; auth=none
- References: <CAK5mtey=C09DO0VTy0kK5vFNA5dasY4kdu6xc=rs5pOhsqy0rw@mail.gmail.com>
On 06/27/2017 07:59 PM, Victor Rodriguez wrote:
> I am trying to port the bench test to a most stable and usable
> platform like https://openbenchmarking.org/ in order to give others
> the capability to measure the performance of new glibc releases
That sounds very interesting. Please keep us updated on how that goes.
It would be interesting to see how such a tool handles the data over time.
> I am trying to understand the output of bench.out:
>
> "ffsll": {
> "": {
> "duration": 2.3834e+10,
> "iterations": 5.5869e+09,
> "max": 54.589,
> "min": 4.246,
> "mean": 4.26605
> }
>
> duration according to benchtests/bench-timing.h
>
> 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.
--
Cheers,
Carlos.