Zebras hate you for no reason: Why Amdahl's law is misleading (2017)
embeddedrelated.com
embeddedrelated.com
For example, if a common update transaction occurs once a second and takes 1.1 second, then the transactions from different users will overlap in time, possibly blocking each other on locks. Speeding up something like this just a little bit will drop the time to 0.9 seconds, reducing the percentage chance of overlap significantly. That has a compounding effect so the queries might suddenly take 0.5 seconds due the lack of lock contention!
There are similar effects due to sharing of CPU caches when queries run concurrently. Even if they’re independent, the hardware isn’t!
Getting to the point that they all run in isolation might not take much effort, but yield dramatic benefits.
What I’ve seen over and over is people who won’t look at single digit percentage improvements because those aren’t “enough”. But the thing is that if you are trying to cut time in half, the 6% for that one method is 12% of your target. So they’re optimizing the way some people do personal finances.
Some of them get “there” in the end, but the road they take is longer and ineffective. When you are looking at four slow methods in a particular flow, you have the perspective of seeing them as parts of a whole. Maybe there’s a way you can rewrite these 4 methods into three that do less, or five where we avoid work in the common case.
If you do them one at a time, and prioritize new ones as they cross your artificial and inaccurate threshold. you won’t see these options, and if you do you’ll talk yourself out of it because you already spent a bunch of effort on what you have now (sunk cost).
Is the key insight here that you shouldn't be depressed if your optimization gains are small because maybe you are mis-estimating the worth of a small optimization?
I mean i guess, but taken in the abstract the advice is basically: don't worry if you don't succeed, because you probably don't know enough to even evaluate if you failed. Which is a pretty depressing take.
There's a whole story (about a criminal api venture) where the point is stated that speed-ups that look pretty small have knock on effects that allow for opportunities elsewhere, and that these opportunities snowball until something significant happens.
It is true that knock on effects are a thing, and small fixes can sometimes have suprisingly big returns. However most small fixes do not, especially in programming. The art of optimizing is understanding the problem well enough to find the right 1% speed improvement to make, because you cannot do all of them and most don't.
What i took away from the article (after all the obnoxious long winded irrelavent tangents that went nowhere), is basically dont dispair if the fixes look small because you might accidentally stumble upon an important one that isn't small without realizing it. Which i find to be a depressing, two wrongs sometimes make a right, take.
If Donald Knuth suffers from this as well then I wouldn't berate myself too much about it, his famous quote that 'premature optimization is the root of all evil' then you're more than excused to let optimization rest until the code is correct (which is far more important than that it is fast) and then use a profiler to tell you where to most efficiently apply your attention. This will get you to a very high percentage of the optimum in a relatively short time.
If you enjoy that type of game, I highly recommend Kittens Game as the pinnacle of the genre—especially since it doesn't feature any microtransactions or dark patterns, but be warned: it can be incredibly addicting.
Take all the ones you can find that aren't DRM'd. Put them on a list to open when you get the itch and open up ye olde javascript console after playing one for a day or two.
https://www.youtube.com/watch?v=NNnIGh9g6fA&list=PL848F2368C...
…namely, that every time we get more efficient at using energy, we increase the amount we produce of it. Instead of doing the same things with less energy, instead we are now able to do new things that were cost prohibitive previously.
It's not a law, of course, or at least not a simple one. E.g., the cost to refrigerate has come down similarly, but while air conditioning continues to increase in use, average freezer/fridge space plateaued in the 1980s. Everyone seems to now have as much freezer space as they want. Some demands are fully satisfiable and people don't necessarily consume more, even as the cost comes down.
Often those limits are the results of other aspects - but there’s not real downside to lighting everything with the fury of ten thousand suns. Besides the dark sky loss.
Paperclips have nothing on it. I warn you!
Now let me go reset, I think this time with a Challenge …
As to the article, it's a good point - optimizing something can provide more benefits than it seems at first, especially over time.
Increasing efficiency doesn’t always mean shorter runtime, sometimes it means more production from an equal runtime.
Lots of improvements to different places in the pipeline can pay off.
Sometimes an improvement in one part of the process can have synergistic knock-on effects in other, perhaps unexpected, parts of the larger system. It seems like these can be hard to predict without taking a deep look at the larger system and how all of its component parts interact.
Once it was a FTTX CPE, and it needed to ship but the binary was a couple KB too big. The programmer on the project found a little bit of savings but not enough. I looked at the code, looked at the assembly output, and found a spot where a switch/case was being transformed into a huge jump table that was mostly sparse. (The embedded toolchain compiler wasn’t great at optimization.) A little refactor to this one function was enough savings to be just under the limit for whatever chip they were using. (I feel bad for the next person who has to fix a bug in that product.)
The relevant aspect to my story is that sometimes an improvement in one area can make another area worse! But that’s ok, because even though my function rewrite was almost certainly slower, we had cpu cycles to spare but not enough storage.
I think the conclusion at the bottom captures most of it.
The main way by which we do that is to compile everything and to improve the compiler to make everything faster. And by making faster machines.
After that it's hard work. If you find that your program spends its time in small fractions of percentages all over the code, and it's compiled well, it may be very hard to keep the structure of that computation as-is while obtaining any significant improvement.
I wonder if there's some better term around than "compiler optimization" for doing really ambitious program transformations, in the vein of program specialization/partial evaluation treating the program and its inputs as a single symbolic system to optimize for evaluation or kolmogorov complexity. I have a feeling that by missing this terminology we're already handicapping work in the area...
This is more insightful than I first thought - and explains a lot about share and stocks and office life
I suppose I better stay far, far away from idle games. For my entire life.