[Pixman] RFC: Pixman benchmark CPU time measurement

Pekka Paalanen ppaalanen at gmail.com
Wed Jun 3 01:33:06 PDT 2015


On Wed, 3 Jun 2015 10:51:25 +0300
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Wed, 3 Jun 2015 08:38:25 +0300
> Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote:
> 
> > On Tue, 2 Jun 2015 10:32:35 +0300
> > Pekka Paalanen <ppaalanen at gmail.com> wrote:

> > > I would propose the following:
> > > 
> > > - runtime clock selection with this priority order:
> > > 	1. clock_gettime(CLOCK_PROCESS_CPUTIME_ID)
> > > 	2. getrusage(RUSAGE_SELF) -> rusage.ru_utime (user time)
> > > 	3. gettimeofday()
> > > 	4. clock()
> > >   Naturally with build time checks, too. For 3 and 4 would print a
> > >   warning about inaccurate measurements. clock_gettime(CLOCK_MONOTONIC)
> > >   is not in the list because I would assume getrusage() is more widely
> > >   available and I'd like to use process time before wall-clock delta.
> > > 
> > > - A separate void init_gettime(void) for choosing the clock.
> > > 
> > > - void gettime(struct timespec *ts) for reading the clock.
> > > 
> > > - double elapsed(const struct timespec *begin, const struct timespec
> > >   *end) for getting the elapsed time in seconds.
> > 
> > This API looks excessively complicated to me.
> 
> Only if you keep the assumption that using a double for absolute
> timestamps is always fine. You always compute time intervals anyway.
> 
> This would even give a nice common place to detect clock wraparounds or
> going backwards so you'd be guaranteed to never get a negative interval
> length.
> 
> If we need runtime detection of available clocks, then having
> init_gettime() would be useful to detect once instead of per OpenMP
> thread.

Sorry, nevermind this, there is no threading in benchmarks. So, the
explicit init call is not necessary, and like Bill pointed out, one
could during the first call not just init but also take the base
timestamp and always return elapsed time from that.

I could keep the API exactly like it is right now.


Thanks,
pq


More information about the Pixman mailing list