www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/11/07/20:58:04

Date: Mon, 7 Nov 94 18:25:15 GMT
From: dolan AT fnoc DOT navy DOT mil (Kent Dolan)
To: dj AT stealth DOT ctron DOT com
Subject: Re: clock() problems
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu

>> 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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019