From:	Charles Sandmann <sandmann AT new-orleans DOT NeoSoft DOT com>
Subject:	Re: clock() problems
To:	dj AT stealth DOT ctron DOT com (DJ Delorie)
Date:	Mon, 7 Nov 1994 21:37:05 -0600 (CST)
Cc:	dolan AT fnoc DOT navy DOT mil, djgpp AT sun DOT soe DOT clarkson DOT edu

> > Probably it is more than time for the "powers that be" to confess that
> > 32 bits is no longer sufficient time resolution when gate speeds are
> > in femtoseconds and time since the epoch is in decades.
> > 
> > A good start would be a structure of two thirty-two bit longs, with the
> > binary seconds point between them.
> 
> gcc supports "long long", which is 64 bits.  If we scale that to
> microseconds, it's good for about 584942 years.  Is it worth the
> performance penalty?

I don't think so; think about the compatibility problems with current
code out there.  Since we don't update the tics nearly that often,
decreasing the clocks per second constant makes more sense in my mind.
Would 1/10 ms be enough accuracy, assuming we actually updated the tics
more often than once each 55ms?

- Raw text -