6 ms·
I wasn't able to find any real justification beyond (a) one vague mention of "some algorithms... such as certain cryptographic algorithms" and (b) the fact that
by kevhito 10y ago
I wasn't able to find any real justification beyond (a) one vague mention of "some algorithms... such as certain cryptographic algorithms" and (b) the fact that clang supports it. Can you point to something more specific? Justification (b) in particular smells bad to me.
- steveklabnik 10y agoI wasn't involved in the discussion really, so I don't have anything off-hand. I can see why (b) might smell a bit bad, but think of it this way: we share a backend with clang, and so if they think support is mature enough to ship, then that's a very positive sign.
- kevhito 10y agoOh, just found this: > The Duration type could be simplified with this: instead of using a u64 for seconds with a seperate u32 for nanoseconds, it could just be a single u128/i128 count of nanoseconds. Of course, just a single u64 at ns precision would get you 500+ years of range. But ok.
- eropple 10y agoFive hundred years and eighty-four years? Recorded human history is almost ten times that range and history to which we can get precise dates is nearly five times that range. There are financial debts being paid, today, that exist from nearly the limit of that range (Dutch debts dating from 1624) even if you left a mere quarter of it for the future. So why are you middlebrowing at this?
- Veedrac 10y agoTo be fair, you basically never need scale and precision at the same time. Debts from 400 years ago aren't known down to the nanosecond.
- eropple 10y agoI can think of astronomical measures from a couple hundred years ago that are at least second-accurate. Do you want to have DurationSecondsOnly and Duration as types? =)
- Veedrac 10y agoIt's more an argument for floating point.
- TillE 10y agoFloating point is awful if you care about precision.
- Veedrac 10y agoWhat scenario would you need more than 53 bits of precision in a time variable for? Even eropple's somewhat excessive subsecond-accurate timing for an event several hundred years ago has plenty of room to spare with 53 bits.
- MaulingMonkey 10y ago"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 ...
- lifthrasiir 10y agoIt is closely related to "native" time representation, where you can frequently have u64 seconds in the API. Being able to represent them without a trap would be beneficial.
- dom0 10y ago64 bit ns timestamps are ok if you are only recording current events, but are completely insufficient as a general purpose timestamp.
- fulafel 10y agoThe x86-64 64x64->128 instructions.