Year 2038 preparations in 3.17 - why not use floating point?
Year 2038 preparations in 3.17 - why not use floating point?
Posted Aug 13, 2014 22:17 UTC (Wed) by rbthomas (subscriber, #39239)Parent article: Year 2038 preparations in 3.17
1) it's fast on modern processors (even on fixed-point embedded processors there are highly optimized macros to perform floating point arithmetic)
2) It's "fail-soft" in that there is a trade-off between precision and larger numbers. It would give micro-second resolution for about 147 years before or after the epoch and milli-second resolution for 147,000 years, nano-second resolution for about 52 days, and pico-second resolution for a little over an hour.
If the epoch is the normal UNIX epoch of Jan 1, 1970, we would have micro-second resolution on timestamps between 1823 and 2117.
For time measurements that require nano- or pico- second resolution, you can define the epoch to be anything you want as long as you can measure it with that resolution. So if I set the epoch for a given set of computations to be the present moment, I can represent measurements over a period of 104 days at nanosecond or better resolution.
Posted Aug 14, 2014 9:01 UTC (Thu)
by etienne (guest, #25256)
[Link]
Because that would mean managing floating point in the kernel, and that would mean saving/restoring the floating point registers at each task switch - instead of only when they have been used by the user-mode task...
Posted Aug 14, 2014 12:09 UTC (Thu)
by JGR (subscriber, #93631)
[Link]
Being able to change the epoch at will, and being able to regularly update the clock with small increment ticks, imply storing the "master" value in some other higher-precision format, in which case you might as well just use that for everything.
Year 2038 preparations in 3.17 - why not use floating point?
Year 2038 preparations in 3.17 - why not use floating point?
Migrating to floating point would be far more painful than bumping an integer from 32 to 64 bits.