You should be very careful when doing that. It may be rare in practice, but it's surprisingly easy to trigger ABA issues with only a 16-bit sequence number.
Don't you need 65k threads all contending on the same state for that to happen? Even if your process does have 65k threads, you'd need a pretty large critical section for all of them to be preempted in an unlucky point.
That said, it's better to rely on RCU/hazptr to solve ABA issues, but the extra bits are still useful to store state that can be CAS'd together with the pointer.
I don't really believe that it is easy to trigger. The thread would have to be preempted at a very specific point for a very specific duration, the other thread(s) would need to perform exactly 2^16 operations within that time window and the final operation would need to trigger the ABA problem. Possible, but extremely unlikely. (In some applications even impossible.) Do you happen to have some real world examples?
But yes, it is definitely something to be aware of!
BTW, if the pointers are always aligned, the sequence number may have a few bits more.
Yeah, it tends to be low single digit percents, but you can get some pessimal behavior if you have enough tiny functions because the overhead of what Cpython exposes starts becoming large. Our "benchmark" where the 10% comes from is tensorflow, which is overwhelmingly tiny functions and no sustained io/individual functions.
Most of the work is done via a C extension, which I suspect would be incompatible with MicroPython. The same techniques are presumably applicable, depending on how many interesting hooks MicroPython exposes.
Working at a company that cared deeply about correctness and reading code over writing it was critical to my current coding style and beliefs. I've written about some of this at https://programsareproofs.com/articles/singleuse_functions.h..., but I developed an aversion to single-use functions, premature abstractions, and "self documenting" code. The code I write these days is drastically more understandable and modifiable than back when I targeted terseness, minimizing duplicated code, and future proofing.
As far as languages go, learning SML and functional programming was probably the biggest change for me.
As someone who doesn't own a Windows machine and only uses Macs for work, this feels like an outdated perspective. It's been many years since using desktop Linux has required magical terminal incantations (for me at least).
If it says Nvidia, don't touch it. Otherwise, everything seems to just work, and things at least don't get broken arbitrarily by companies whose goals don't match mine. Even all the games I've tried have run solidly with Steam's Proton support.
Maybe I've become numb to them, but I just don't see these painful interactions that get referenced, and don't see why their bogeyman would be worth giving up your freedom to use your machine.
I'd recommend a Zebralight one (I like the H600Fc), as they're small, light, and much brighter than most headlamps you'll find. I've also had good luck with Armytek (Wizard Pro Nichia), though people say their reliability is lower.
I used it to do some tax optimization around ISOs at a newly public company (https://gitlab.com/mbryant/taxoptimizer/-/blob/master/amt.py). It gets pretty slow when you try to look more than a few years out, so I'm guessing writing some optimization logic by hand would've made more sense. Using Z3 here definitely beat me trying to do this on paper like I've seen other people do!
