4 ms·
Fair enough. In case this was a counter, best make sure you get the overflow logic right. The normal 64 bit wrapping won't kick in if you're just able to (de) s
by repelsteeltje 2y ago
Fair enough. In case this was a counter, best make sure you get the overflow logic right. The normal 64 bit wrapping won't kick in if you're just able to (de) seriaize only 61 bits.
Or (depending on the context of this counter) you may never want to overflow at all - in which case you're best of with a variable length representation that is open ended (like r or python arbitrary precision)
- vlovich123 2y agoIt would take your absolute top of the line CPU doing nothing but incrementing the counter for more than 12 years to worry about overflowing a 61 bit number. And what this is counting is much more expensive than incrementing a counter so you can’t run this at 6Ghz. Maybe ~500mhz which gets you to > 100 years if that’s all you’re doing but this counter is a side operation that won’t see much traffic even at scale so you’re talking about millennia in practice I suspect. So it’s just not a practical concern - I just panic if it hits the limit. I think you may be failing to comprehend just how large numbers like this get and how long it takes to count because it’s such a very real concern with 32 bit counters. Addition of course can always overflow but this is a straight up strictly monotonic counter that counts from 0 to 2^61.
- repelsteeltje 2y ago:-) fair enough. And panicing is exactly the kind of mitigation I had in mind initially; just don't silently do the unexpected. > I think you may be failing to comprehend just how large numbers like this get On the other hand, us programmers are also notorious for failing to comprehend just how long our software will live on...
- vlovich123 2y agoHonestly if any code I’ve written survives 100 years to cause problems I’ll be impressed. 1000 years I’ll be ecstatic.