On Wed, 3 Jun 2015 10:51:25 +0300 Pekka Paalanen <[email protected]> wrote:
> On Wed, 3 Jun 2015 08:38:25 +0300 > Siarhei Siamashka <[email protected]> wrote: > > > On Tue, 2 Jun 2015 10:32:35 +0300 > > Pekka Paalanen <[email protected]> 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 _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
