[Haskell-cafe] Re: System.CPUTime and picoseconds

[Neil Davies]

I've found the pico second accuracy useful in working with 'rate  
equivalent' real time systems. Systems where the individual timings  
(their jitter) is not critical but the long term rate should be  
accurate - the extra precision helps with keeping the error  
accumulation under control.

When you are selling something (like data bandwidth) and you are  
pacing the data stream on a per packet basis you definitely want any  
error to accumulate slowly - you are in the 10^10 events per day range  
here.

Neil


On 12 Jan 2009, at 00:00, Lennart Augustsson wrote:

> On Sun, Jan 11, 2009 at 8:28 PM, ChrisK  
> <haskell at list.mightyreason.com> wrote:
>> An Double or Int64 are both 8 bytes and counts with picoseconds  
>> precision
>> for 2.5 hours to 106 days.  Going to 12 byte integer lets you count  
>> to 3.9
>> billion years (signed).  Going to 16 byte integer is over 10^38  
>> years.
>>
>> Lennart Augustsson wrote:
>>>
>>> A double has 53 bits in the mantissa which means that for a running
>>> time of about 24 hours you'd still have picoseconds.  I doubt anyone
>>> cares about picoseconds when the running time is a day.
>>
>> The above is an unfounded claim about the rest of humanity.
>
> It's not really about humanity, but about physics.  The best known
> clocks have a long term error of about 1e-14.
> If anyone claims to have made a time measurement where the accuracy
> exceeds the precision of a double I will just assume that this person
> is a liar.
>
> For counting discrete events, like clock cycles, I want something like
> Integer or Int64.  For measuring physical quantities, like CPU time,
> I'll settle for Double, because we can't measure any better than this
> (this can of course become obsolete, but I'll accept that error).
>
>  -- Lennart
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe