garfieldandthe
Would you rather like to approach this problem by optimizing memory layout which, let's be honest, tends to give you more in the region of 1-10% improvements rather than 10-100x, or would you rather like to try to go from O(n^3) to O(n^2) or O(n log n) or similar?
The real meat is in the complexity class. Cache effects are where you go when there is nothing else to optimize and it actually matters. Preemptively making all your data structures 2-3 as big because of not-actually-necessary padding does not sound right to me, but YMMV.
And even if you do quadratic operations in your handler, how often do you write a new such handler? Most of the time you work on stuff around that, supporting infra, testing, etc. None of those needs to be cache optimized either.
While you are optimizing your struct layout and decrease you app start time from 1.122765 seconds to 1.122764 seconds, I ship production code at 2x the rate because I only optimize for performance where it matters while otherwise optimizing for maintainability, testability, extensibility, dev fun and actually shipping.
And how often do you actually write such code? Most people: Between rarely and never. You write single threaded code or use synchronization primitives. Sure if you are writing a library squeezing performance out of some parallel processing problem then this is relevant, but that's a niche scenario.
> The fix there is absolutely trivial: add padding.
Most common case is that this just wastes memory. Don't micro-optimizr before you know that this is actually a problem.
> Another often-trivial one is avoiding linked lists whenever feasible.
Again, not true, depending on your use case. If the operations that you commonly perform on the data structure, like inserting/deleting elements, then of course you should use a linked list or whatever container data structure your language provides. How caches play into this is at most a second order effect in the common case, unless you really want to optimize a tight loop in a performance critical application.
I've seen too many prematurely applied fancy data structures where it turned out that all this extra complexity was entirely unnecessary and just made things harder to maintain.
The typical programmer should treat CPU caches as what they are designed to be: mostly transparent. You work in a high level language and leave the tricky details to a library and your compiler.
It's only a small minority that should really worry about these things.
In my daily work, I see more often premature microoptimizations (in part using the myths from the article) which are entirely unnecessary rather than code that needs to optimize for those things.
> We demonstrate the application of video-based cryptanalysis by performing two side-channel cryptanalytic timing attacks and recover: (1) a 256- bit ECDSA key from a smart card by analyzing video footage of the power LED of a smart card reader via a hijacked Internet-connected security camera located 16 meters away from the smart card reader, and (2) a 378-bit SIKE key from a Samsung Galaxy S8 by analyzing video footage of the power LED of Logitech Z120 USB speakers that were connected to the same USB hub (that was used to charge the Galaxy S8) via an iPhone 13 Pro Max.
Had this been in a movie, you'd say it's unrealistic and the filmmakers have no clue how technology works.
This is a misconception of scientific endeavour in general and of physics in particular. All models are approximations of reality. We have a theory that is consistent with experimental observations, then we make observations with which the theory is not consistent anymore and we develop a new theory that explains those new observations as well, and so on. We will never have an "exact" model, whatever that even means. But we have models that have limitations that are far beyond what's relevant for most people's life.
At many points in time, we could pat ourselves on the back. The heliocentric model. Newtons model. General Relativity. The Standard Model. All these models were important steps forward and led us to where we are today, which is absolutely astonishing. No, we don't have a full theory explaining everything, but we never will.
One could almost say that not being smart requires you to be harder working. (At least that's what I'm telling myself to keep working hard.)
I stopped reading right there. If everybody did that then perhaps he'd learn to be able to express things without immediately being full of himself.