Messages in this thread | | | Date | Fri, 17 Dec 1999 10:28:43 -0800 | From | Dan Kegel <> | Subject | Re: gettimeofday() a special case : faster than times()? |
| |
Mark Hahn wrote: > > Here's a newbie question about the merits of gettimeofday() > > versus times() for implementing one's own little timers. > > gettimeofday returns elapsed (real) time in us. times returns > various times in scheduler ticks (10ms on ia32).
already understood. I was using the return value of times() only, which is the elapsed real time in scheduler ticks since boot.
> > gettimeofday(&tv, 0) would work, but I'd have to munge the > > fields of tv together to get a single integer, e.g. > > now = (tv.sec << 10) + (tv.usec >> 10) > > do you have a reason to believe that this kind of inaccurate scaling > saves you more than a handful of cycles?
I don't need more than ms precision. Also, it's a matter of convenience. If I switch to using tv's, my time comparison macro
inline bool clock_after(clock_t a, clock_t b) { long diff = (long) (a - b); /* avoids rollover errors */ return (diff > 0); }
gets more complicated:
inline bool tv_after(const struct timeval &a, const struct timeval &b) { long diff = (long) (a.sec - b.sec); if (diff) return (diff > 0); /* avoids rollover errors */ return a.usec > b.usec; }
and I was too lazy to write it until just now. I've been using system ticks for this longer than I can remember, so there was a certain intertia... plus now I have to make sure tv_after works.
> > Do the recent posts on special entry points mean that this > > would be faster than calling times()? > > not really. the syscall overhead dominates either call. but gtod > is going to do more work (reading either the TSC or the counter/timer chip > to calculate accurate time) than times (which just pulls a few tick-counters > out of the process struct.
See http://kernelnotes.org/lnxlists/linux-kernel/lk_9912_02/msg00232.html (a way to eliminate the syscall overhead) and ensuing discussion. If this ever makes it into a real kernel, gtod() might be faster than times().
> > Am I better off using gettimeofday() anyway because of > > its higher precision and clearer specification? > > how is times unclear?
Nowhere in the man pages does it explain what units 'clock tick' are in. Following the man pages leads you to CLK_TCK, which is wrong (it's 1000000 rather than 100). Only by oral tradition does one discover HZ or (much better) sysconf(_SC_CLK_TCK). IMHO 'man times' should mention sysconf(_SC_CLK_TCK), and depricate HZ, CLK_TCK, and CLOCKS_PER_SEC. Note also that 'man sysconf' claims that sysconf(_SC_CLK_TCK) == CLK_TCK, which is untrue.
I'm still a bit confused about all that. I believe that SUS mandated a certain value for CLOCKS_PER_SEC. Better to just erase it from the face of the earth, since a compile time constant is just wrong for the units of system scheduler ticks. - Dan
-- (The above is just my personal opinion; I don't speak for my employer, except on the occasional talk show.)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |