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

[ChrisK]

Tony Finch wrote:
> The FreeBSD kernel uses a 64+64 bit fixed point type to represent time,
> where the integer part is a normal Unix time_t. The fractional part is
> 64 bits wide in order to be able to represent multi-GHz frequencies
> precisely.

"multi-GHz" being a euphemism for 18.45*10^9 GHz, over 18 billion GHz.

I just read through that. The granularity is 2^-64 seconds, or 5.4*^-20 seconds? 
That is 54 nano-pico-seconds.  I can see needing better than nanosecond, and 
going to milli-nanoseconds like Haskell, but to jump close to pico-nano-seconds? 
  That skips right past micro-nano-seconds and nano-nano-seconds.  That's 20 
million times more resolution than Haskell's picoseconds.  My that was fun to write.

It looks like an excellent performance hack for OS kernels.  64-bits make for 
simple register and cache access, the compiled code is small and quick, etc.

As a portable API it is far too complicated to use.  Not in the least because 
only FreeBSD probably has that API.

Note that at 10^-20 seconds the general relativistic shift due to altitude will 
matter over less than the thickness of a closed laptop.  Defining "now" that 
accurately has meaning localized to less then your computer's size.  The 
warranty for the bottom of your screen will expire sooner than that of the top.

Only stock traders and relativistic particles care about time intervals that 
short. "FreeBSD — designed for the interstellar craft to tomorrow"

Hmm...The W and Z bosons decay the fastest with 10^-25 second lifetimes, the 
shortest known lifetimes that I can find.  The fundamental Planck scale, the 
shortest amount of time in today's physics, is 5.4*10^-44 seconds.  So with 80 
more bits FreeBSD would be at the fundamental limit.  Of course the conversion 
then depends on the values of h, c, and G.

Now that would also be a good April Fool's joke proposal.

-- 
Chris