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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
