←back to thread

A leap year check in three instructions

(hueffner.de)
420 points gnabgib | 1 comments | 15 May 25 21:57 UTC | HN request time: 1.018s | source
Show context
drewg123 ◴[15 May 25 22:47 UTC] No.44000124[source]▶
I tend to be of the opinion that for modern general purpose CPUs in this era, such micro-optimizations are totally unnecessary because modern CPUs are so fast that instructions are almost free.

But do you know what's not free? Memory accesses[1]. So when I'm optimizing things, I focus on making things more cache friendly.

[1] http://gec.di.uminho.pt/discip/minf/ac0102/1000gap_proc-mem_...

replies(14): >>44000191 #>>44000255 #>>44000266 #>>44000351 #>>44000378 #>>44000418 #>>44000430 #>>44000433 #>>44000478 #>>44000639 #>>44000687 #>>44001113 #>>44001140 #>>44001975 #
drewg123 ◴[15 May 25 22:57 UTC] No.44000191[source]▶
To temper this slightly, these sorts of optimizations are useful on embedded CPUs for device firmware, IOT, etc. I've worked on smart NIC CPUs where cycles were so precious we'd do all kinds of crazy unreadable things.
replies(2): >>44000245 #>>44000547 #
bigiain ◴[16 May 25 00:02 UTC] No.44000547[source]▶
I suspect most IOT device manufacturers expect/design their device to be landfill before worrying about leap year math. (In my least optimistic moments, I suspect some of them may intentionally implement known broken algorithms that make their eWaste stop working correctly at some point in the near future that's statistically likely to bear beyond the warranty period.)
replies(1): >>44001037 #
crote ◴[16 May 25 01:34 UTC] No.44001037[source]▶
"Is year divisible by four" will work perfectly fine for the next 75 years. Random consumer devices are definitely not going to survive that long, so being capable of dealing with it adds exactly zero value to the product.

It's hard to imagine being in a situation where the cost of the additional "year divisible by 100" check, or even the "year divisible by 400" check is too much to bear, and it's trivial enough that the developer overhead is negligible, but you never know when you need those extra handful of bytes of memory I guess...

replies(1): >>44012244 #
1. bigiain ◴[17 May 25 05:28 UTC] No.44012244[source]▶
> but you never know when you need those extra handful of bytes of memory I guess...

I guess on all those crappiest of 32 bit devices with 2.6 based kernels (which are practically unupgradeable due to vendor patches[1]) which will never make it to 2100 to the "year divisible by 100" check, because their time_t overflows in 2038.

On the plus side, that overflow turns the date into 1901, so perhaps they won't actually blow up due to leapyear bugs for another couple of years? That'll be a fun vintage computing archeological bug fix for someone.

[1] I am at least partly responsible for one of these products from a failed hardware startup I work at in 2012/13.