Mail Archives: djgpp/1994/11/07/20:58:04
>> Also, the macro CLOCKS_PER_SECOND is 1000000, which means clock()
>> returns its results in microseconds. But that means that its
>> value (a signed long) will only be wide enough for programs
>> which run less than about 40 minutes, right? Is this wise?
> You can use time() for periods longer than that with sufficient
> resolution, but perhaps a bigger "tic" would be in order. The
> alternative is to program clock() to read the microsecond counter in
> the interval timer, so it can return actual resolution around a
> microsecond?
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.
[A more foreward looking change would probably just go ahead and
put 1024 bits on the left of the binary point and 512 bits on the
right of the binary point and be done with it. That takes you a
little farther than the 10**-43 seconds resolution of the
monoblock on the right, and to the 10**100 seconds heat death of
the universe on the left, surely sufficient resolution.]
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 -