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: OndÅej BÃlka <neleai at seznam dot cz>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 23 Apr 2013 14:42:33 +0200
- 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> <20130423121544 dot GS16329 at spoyarek dot pnq dot redhat dot com>
On Tue, Apr 23, 2013 at 05:45:45PM +0530, Siddhesh Poyarekar wrote:
> 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.
>
Having fallback is independent to setting HP_TIMING_AVAIL. We can define
fallback but then keep HP_TIMING_AVAIL zero.
> 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
--
LBNC (luser brain not connected)