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:     )
<dolan AT fnoc DOT navy DOT mil>  <dolank AT fnoc DOT navy DOT mil>  <xanthian AT well DOT sf DOT ca DOT us>

- Raw text -