This is the mail archive of the libc-alpha@sourceware.org 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: [PATCH] Use HP_TIMING for benchmarks if available


On Tue, Apr 23, 2013 at 11:19:43AM +0530, Siddhesh Poyarekar wrote:
> On Mon, Apr 22, 2013 at 08:41:12PM +0200, OndÅej BÃlka wrote:
> > I thougth instead ask in separate thread if it would be possible. It
> > would make hp_timing more usable.
> 
> OK, but the correct alternative for hp_timing would be
> CLOCK_MONOTONIC_RAW and not CLOCK_PROCESS_CPUTIME_ID.  For
> benchmarking I would prefer the latter for a lot of cases since it
> does not include scheduling costs.
> 

OK I looked at how this can be done in a more generic manner.  On
non-linux systems, clock_gettime uses HP_TIMING whenever it is
available as a fallback for clock ids that are not defined, or else
return EINVAL.  If we make HP_TIMING have a safe fallback to
clock_gettime and always set HP_TIMING_AVAIL, we could end up breaking
stuff for non-linux systems that do not otherwise have HP_TIMING
support since it will eventually result in an infinite recursion.  I
don't have any non-HP_TIMING_AVAIL hardware, nor do I hack on hurd, so
I don't mind removing this.  However I'm sure someone on this list
will care about this.

Effectively, we need to clock_gettime fallback only for performance
tests and hence it currently does not make sense to put it in generic
code.

Besides, the very definition of HP_TIMING (high precision, low
overhead) does not match up with clock_gettime, since the latter is
not necessarily low overhead.

Siddhesh


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