Date: Mon, 7 Nov 94 13:34:39 -0500 From: dj AT stealth DOT ctron DOT com (DJ Delorie) To: dolan AT fnoc DOT navy DOT mil Cc: djgpp AT sun DOT soe DOT clarkson DOT edu Subject: Re: clock() problems Status: R KPD> Probably it is more than time for the "powers that be" to confess that KPD> 32 bits is no longer sufficient time resolution when gate speeds are KPD> in femtoseconds and time since the epoch is in decades. KPD> A good start would be a structure of two thirty-two bit longs, with the KPD> binary seconds point between them. DJD> gcc supports "long long", which is 64 bits. If we scale that to DJD> microseconds, it's good for about 584942 years. Is it worth the DJD> performance penalty? Given a choice between a broken mechanism and a slow one? Yes. I suspect that timings in nanoseconds might be useful even now, with the clock on the TI DSP chip running at order of magnitude 1 GHz, so microsecond might be too coarse if you're going to go to the trouble of making a change. 585 years is still pretty good for timing a program, and by the time there is an operating system with uptime that outlasts the usual survival time of the society operating the computer, there will be time for another fix to be done by our distant descendants. Xanthian. -- Kent, the man from xanth. Kent Paul Dolan, CSC contractor at Fleet Numerical. (408) 656-4363. (Navy Unix email: ) (Navy cc:Mail email: ) (real world email: )