
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.
That's why I think a Double is a good choice, it adapts to the time
scale involved.
-- Lennart
On Sun, Jan 11, 2009 at 4:03 PM, Peter Verswyvelen
wouldn't a double become less and less precise the longer the process is running? so Integer sounds like the only datatype that could work here... and why not do it like in Windows: make two functions, one that returns the number of CPU ticks, and another that returns the frequency (number of ticks per second)... This gives you an API that works for whatever clock speed...
On Sun, Jan 11, 2009 at 11:23 AM, Lennart Augustsson
wrote: It was suggested that it should be ns, and I complained that ns would be obsolete in a while. What I really wanted was a switch to Double (and just using seconds), instead we got ps. At least ps won't get obsolete in a while.
-- Lennart
On Sun, Jan 11, 2009 at 12:06 AM, ChrisK
wrote: Manlio Perillo wrote:
Hi.
Just out of curiosity, but why Haskell 98 System.CPUTime library module uses picoseconds instead of, say, nanoseconds?
At least on POSIX systems, picoseconds precision is *never* specified.
I have not idea. But at a guess, I would say that 1 ns is not such a small time interval anymore. The CPU speeds are about 3 GHz, so 0.3 ns per CPU clock. Even the RAM clock in a laptop (e.g. Apple's 17" Mac Pro) is 1066 MHz, so the internal there is just under 1 ns.
Whoever picked picoseconds has made it possible to talk about a single clock interval for hardware like this.
-- Chris
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe