This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Use HP_TIMING for benchmarks if available
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 23 Apr 2013 17:45:45 +0530
- Subject: Re: [PATCH] Use HP_TIMING for benchmarks if available
- References: <20130415081936 dot GN9444 at spoyarek dot pnq dot redhat dot com> <20130422050122 dot GC1412 at spoyarek dot pnq dot redhat dot com> <20130422145502 dot GA31451 at domone dot kolej dot mff dot cuni dot cz> <CAAHN_R31nOZOhF6wD_qN=BKtPwtUB=xu+PPrXXu5x2KBOoZAiw at mail dot gmail dot com> <20130422184112 dot GA2873 at domone dot kolej dot mff dot cuni dot cz> <20130423054943 dot GE16329 at spoyarek dot pnq dot redhat dot com>
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