3 ms·

"Absolute" timestamps. If you're using a double to represent, say, epoch time (technically relative to the relatively recent 1/1/1900), your precision has drop

"Absolute" timestamps. If you're using a double to represent, say, epoch time (technically relative to the relatively recent 1/1/1900), your precision has dropped off to about half a microsecond or so. I read GPU profiling results in nanoseconds. You can work around the problem - time since program start, time since capture start, etc. - of course, this can lead to fun edge cases, where e.g. Windows 95/98 crashed due to a 32-bit milliseconds timer rollover after around 50 days. For comparison, pow(2,53) nanoseconds is only a little over 100 days. Of course, a floating point value won't roll over in quite the same way, but... The problem is surmountable if you throw enough edge case handling at the problem. Force the devs to be vigilant about choosing the necessary precision, the proper time to measure relative to, for each possible application of anything time related, etc... ... or you could just throw more bits at the problem, and suddenly my accounting software can accurately calculate compound interest on both a 400 year old debt, and a 49 nanosecond debt clearing HFT trades, if that's your kind of thing - without as many edge cases to worry about. EDIT: Use pow(x,y) formatting since HN collapses x double-star y to simply xy ...

Veedrac 10y ago
Yeah, sorry, that was a bit of a knee-jerk response from me. I took TillE's comment to be more a statement of the general (IMO unfounded) mistrust of floating point, and my comment was intended to take it in that light. Once you have values in the domain you're interested in, floating point more than suffices for precision, and generally handles rounding better than the equivalently-sized fixed point variable. I do agree that a general timestamp needs to be domain-agnostic, and I'm certainly not saying Rust should use it, not least because Rust aims to preserve the semantics of underlying APIs.
planteen 10y ago
Here's another example like your Windows rollover - timing rollover caused the loss of the Deep Impact spacecraft. "On September 20, 2013, NASA abandoned further attempts to contact the craft.[76] According to A'Hearn,[77] the most probable reason of software malfunction was a Y2K-like problem (at August 11, 2013, 00:38:49, it was pow(2,32) of one-tenth seconds from January 1, 2000)" https://en.wikipedia.org/wiki/Deep_Impact_(spacecraft) https://en.wikipedia.org/wiki/Deep_Impact_(spacecraft)

Veedrac 10y ago

Yeah, sorry, that was a bit of a knee-jerk response from me. I took TillE's comment to be more a statement of the general (IMO unfounded) mistrust of floating point, and my comment was intended to take it in that light. Once you have values in the domain you're interested in, floating point more than suffices for precision, and generally handles rounding better than the equivalently-sized fixed point variable. I do agree that a general timestamp needs to be domain-agnostic, and I'm certainly not saying Rust should use it, not least because Rust aims to preserve the semantics of underlying APIs.

planteen 10y ago

Here's another example like your Windows rollover - timing rollover caused the loss of the Deep Impact spacecraft. "On September 20, 2013, NASA abandoned further attempts to contact the craft.[76] According to A'Hearn,[77] the most probable reason of software malfunction was a Y2K-like problem (at August 11, 2013, 00:38:49, it was pow(2,32) of one-tenth seconds from January 1, 2000)" https://en.wikipedia.org/wiki/Deep_Impact_(spacecraft) https://en.wikipedia.org/wiki/Deep_Impact_(spacecraft)