I HATE "premature optimization is the root of all evil" (sometimes)
ฝัง
- เผยแพร่เมื่อ 18 มี.ค. 2024
- get.hazelengine.com
cherno.live
Patreon ► / thecherno
Instagram ► / thecherno
Twitter ► / thecherno
Discord ► / discord
Hazel ► hazelengine.com
🕹️ Play our latest game FREE (made in Hazel!) ► studiocherno.itch.io/dichotomy
🌏 Need web hosting? ► hostinger.com/cherno
💰 Links to stuff I use:
⌨ Keyboard ► geni.us/T2J7
🐭 Mouse ► geni.us/BuY7
💻 Monitors ► geni.us/wZFSwSK
People fail to draw the line on when they are skilled enough that optimizing while writing is better than leaving it for later after measuring the weak spots
Well said
you gotta find balance. If you worry too much the project will never end if you don't worry at all its gonna be all over the place
People take Knuth’s quote out of context. The full quote is “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil”. The quote’s intention was to mean programmers should focus on other issues, like good algorithm design and implementation, before worrying about micro-optimizations.
same as people misquoting “the blood of the covent is thicker than water of the womb” as “blood is thicker than water”
@jacobmars1902 that's actually wrong. The original quote is "I also hear it said that kin-blood is not spoiled by water", which comes from the German epic Reinhardt Fuchs and over time transformed into "blood is thicker than water". There's not really any sources for your version of the quote, at least none that i could find while doing some quick research.
I recall that the original version talked about premature optimization in assembler
I appreciate the parallel advice Sutter offered in C++ Coding Standards:
Don't optimize prematurely
Don't pessimize prematurely
Its better to get something working so you have a base to improve on and measure against rather than speculatively "optimizing" without any measurable standard, but that doesn't mean throwing experience and engineering out the window either. The first stab should seek to be reasonably performant while still being maintainable and understandable and otherwise meeting the project's goals. Then measure and find the real issues snd improve it until it is good enough.
It's a distorted version of the original quote. Hoare was warning people off things like cycle counting/micro optimizations prior to things like core algorithms being settled, unless it was absolutely necessary. But as you said, if a problem's demands exceed the resources available given a simple solution then you better factor that in from the outset.
Being a software engineer formerly in automotive, I was at some point enrolled to an internal combustion engine course back in the days.
This saying was formulated by the mechanical engineer who was presenting:
_Premature local optimization will in turn make system integration hard or impossible._
It means that engineers living in their small boxes will keep cutting corners for their own benefit (whether its comfort or meeting specs, habitual over-engineering etc.) until they eventually turn components incompatible with their surroundings.
Such optimizations, most of the time, yield diminishing resturns or even a net loss as everyone else is trying to adapt to those who think they know better.
I remember the first time I learn to code.
There are many if statements that I made/wrote. It's about 600 lines of code.
After I learn that it can be solved by mathematics and some sort of object oriented programming concepts, I begin to fall in love with math. Because every function could be written in one line of code.
From then, my first strategy is that, can mathematics solve this problem?
If it can, then continue using that approach.
But if it cannot, then maybe a common algorithm can help.
That involve playing with variables, local temporary variable and an abstracted data structure defined by the standard library. Play around with these we get algorithm.
Forgot to mention the inline keyword in system programming languages like c++, the pointers, references.
The move semantics right. Because programmers hate deep copying.
Lifetime, etc etc.
Example of solution that can be solved by math?
@@ald5397 There are many , kid. You just have to search for it.
For my case, I use normalized vector additon or unit vector additon or something like that to find whether a point lies in a triangle or not.
"Premature" is very vague in the quote. If you was have the similar situation with the similar problems in the past, then optimizations just can't be premature. For me this quote is just scientific method in programming and no wasting efforts on the problems, if you don't know are they really problems
I think the issue with optimizing too early in a project is optimizing the algorithm before all the requirements or ramifications are known, and potentially investing a lot of time in something that's not needed. But if you know you need to write something that does xyz and you know an optimized way writing it, then do that.
I also agree with Chero that with more experience you'll recognize slow or memory wasteful way of doing things and write them better from the start.
The quote is about code "cleanliness", not initial performance
I like writing the simplest possible *optimizable* code, that way additive optimizations like simd or threading are somewhat easy to do when necessary in the future.
If you're doing subtractive optimizations (removing layers of abstraction to make things go faster) that's a sign of bad architecture
It's also about optimizing so hard that code becomes unreadable or unadaptable.
It's always striking a balance between optimized for machine or for human.
Well what I do is put a "TODO: optimize this below code" whenever I dont have time to think of an optimal solution with the hope that someone else will do it in future.
There are things that are quite a bit more work when written in a more optimized way and provide very little benefit. But for some things it's pretty clear from the beginning that they will be determining a large part of the performance of whatever you are building. The quote is definitely true for micro optimizations which can and should be done later. But if you make architecture decisions based on this quote, you are not helping yourself. It'll be a lot more work to redesign core components of your application later than starting with a well thought out design.
The quote actually refers to what you said. People misuse it.
I would maintain that anyone who thinks Knuth discouraged optimization hasn’t ready much Knuth or seen any of the little optimizations in his algorithms code. (For example, counting backwards in a loop so that a comparison operation takes one less opcode.)
I'm fond of the phrase "don't let the perfect be the enemy of the good".
You do want to think about optimization but if that prevents you from actually getting something that works that you can understand and iterate on then optimization is the least of your worries.
The choice to hyper-optimize, locally in one algorithm, or one procedure, can impact your architecture. Affecting your architecture can affect your I/O and data transfer. Affecting I/O or doing CPU writes to GPU buffers is going to have orders of magnitude more impact on your times than your for loop. If you are locking a thread, or doing sequential loads when you could parallelize, or fully loading when you could chunk/stream, because you are focused on whether you need an lbvh or an octtree or unaligned bsp... and whether it needs to be built per frame... but you are wasting several milliseconds on loading stuff, or accessing stuff, or writing to the gpu... then your optimizations are busted.
Optimization needs to account for the holistic system design, or it will decimate you in the spots you aren't accounting for. And that's just called architecture.
The part I hate most is when people tend to say that software doesn't "need" to be fast for whatever reason, it sure as hell needs to be fast. Your website absolutely should load quickly.
The balance between "reinventting the wheel" and "building a better mousetrap" and between "prematurely optimizing" and "going fast by default" is usually best approached by recognizing that there is an inverse exponential benefit vs time curve at work, and trying to make sure you're operating in the "sweet spot" range.
you only gain this experience by actually optimizing code you sometimes don’t have to, just to learn that that doesn’t have a huge effect…
I only leave optimization for later when I don't know how to optimize it in the given case. But only if it qualifies as a CBB note.
When it comes to multithreading, what are some optimization practices that you do when you are initially writing your code, in order to avoid going back and having to rewrite functions and classes just for the sake of optimization?
I feel like calling a multithreading experiment "premature optimization" is a little far. I think it was valid for the chatter to try out an improvement and I applaud them for actually benchmarking it instead of just asserting that it *must* be faster.
Premature optimization would be hand rolling assembly before the architecture of that unit of code is frozen.
It's just something people say to beginners to prevent them from hitting walls. But, try making a game engine in c++ without pre-optimizing and see how far you get.
Don't remember where I heard this, but performance has to be a correctness criteria. I.e. at the beginning you should know if you have a year, a day or a microsecond to complete the algorithm. If you need microoptimizations to get there it will usually be obvious.
I think it was Scott Meyers, many years ago. But it stuck with me.
I absolutely hate this expression because it gets thrown around like cosh with which to beat engineers with, even engineers that have legitimate concerns about performance.
Quoting the pithy sayings from software "gurus" is like a religious apologist quoting a line from the Bible in the expectation that it would simply shut-up any discussion and examination of what may become a critical issue.
You're decently right. So if you are so good, can you please explain how to use a library written in masm64 and compile it with cpp? I can only compile with object file but not with . lib file. Thanks.
Next time I will permutate a list until its sorted. Maybe some thoughts about optimization don't hurt.
Premature optimization to me is planned ng for future features that may or may not come, not optimizing the actual thing your working on.
I like that quote
So, in other words... use a profiler and know what your priorities are?
Premature caching is, indeed
I think "premature optimization" goes hand in hand with YAGNI. Do you really need to spend that extra time just to optimize this new code you've just written? Probably not. That extra performance boost is probably not going to be needed anyway.
Optimization is ... I'll just say it, never, the thing you should worry about. Reliable and maintainable code is key. Half the time there will be software or hardware layers before metal that will do what you are trying to do 10x better. Any optimization should be test and data driven. Having a mental image of what optimal code should look like is just dumb, there is no way to know what should be optimized without testing and profiling first.
Pretty sure if you're capable and write optimized code the first try, then it's not quite premature is it?
That quote is total garbage! I always do programming at least performance aware, so i don't do anything stupid that eats millions of cpu cycles for no reason - but i don't really optimize it. Normally defining data structures in a memory efficient way and transforming multiple data instead of single data is more than enough to get a good stable and fast program/game.
In 99% of all cases, there is no need for hardcore optimization, but you should be aware that your code is running on an actual hardware set and you should treat it that way.
The main problem these days that developers does not do this and have no idea for what system there are program for. This mindset makes me so angry... and are the reason why modern software simply is slow and unstable like hell, which hides under the insane performance modern CPU's have.
I really like that phrasing "performance aware" because it focuses less on the extreme. Optimization it always sounds as if you search for the fastest solution, when we actually just mean a fast or good solution.
@@lainiwakura3741 I didnt made up that phrase, the origin of this is casey muratori and there is actually a online course how to program in a "performance aware" style on the site "computer enhance". I did that course (which is still ongoing) and learned a ton from it - but its not that easy to follow, due to its complexity in modern CPU & memory architecture.
@@F1nalspace Thanks for the tip, I'll check it out
Design inwards, then build outwards.
Plan the work, then work the plan.
Get it done before getting the next thing done.
Start with the "tree trunk" of the project, then apply the above to each feature "branch" added.
This ensures that all optimizations are mature, that each section of work is completed before moving on, and leaving it very clear where and how to add more feature "branches".
If you're experienced enough to write optimized code out of the box, I don't think that qualifies as premature optimization.
Exactly.
Only delay optimization if its either not required, or if you know how it can be optimized later. If you design something that runs terrible, if might still run terrible if you try to optimize it. And then its for the bin.
i think it depends on the setting. A gameengine always has to be fast. If you optimize your code from running in 100ms instead of 500ms and it literally doesnt matter because it is rarely executed and is now 10x more complicated you didnt do yourself a favour.
But fast is relative.
Additionally, if you really, really, really care about fast, then your game engine is going to look nothing like a traditional game engine, and is going to be absolutely miserable to work in, because everything needs to be broken into cache-consistent parallelizable GPU buffers, with some absolutely wild compute shaders, handling absolutely everything, other than the indirect render calls...
...and if you go that hard into "fast", you will probably end up with micro stutters, because you didn't account for the time it takes to feed the buffers, based on input, because your calculations are running at the speed of light, but the I/O to transfer the data pauses your whole system for orders of magnitude longer than the computations. That's a "missed the forest for the trees" problem.
In web systems, I have worked with people insisting on calling out to C++ from a shell on the server, to "go fast"... but then they do 3 blocking db/network calls, in serial, to load the data to pass in, which brings them from saving 30ms by doing the calculations in C++, but spending an extra 400ms, doing sequential data loads...
Meanwhile, the client device could have done most of the calculations... the server would save 430ms+, have 2 fewer languages (bash/fsh/zsh and C++), spin up fewer processes on fewer threads (more availability for more requests for more users) and the user, funnily enough, gets a more responsive experience, because the time for the phone or laptop to do the crunching, or chunked calculating is *still* less than the time for the sequential loads.
The point is that "locally optimized" in an algorithm, unless it's a per-pixel, or big-data calculation on a massive data-set is way, way less important than making sure your architecture and data orchestration are sound. Because your I/O is likely an order of magnitude worse than your single-thread CPU code, and multiple orders of magnitude slower than parallel GPU processes.
And focusing on the local algorithm's speed before solving data-access, can box you into terrible corners that force you to load data in ways that will always be slow, because you have chosen to abandon worrying about everything but localized speed... it can ruin you in I/O. It can ruin you in parallelism. It can ruin you in moving everything to the GPU. It can ruin you in a million different ways, no matter how fast your for loop is.
_"That quote is right, but it's also misleading: there's a difference between premature optimization and taking the clowns out of the car. If you don't take care, it may end up being too late for optimization"_ - Mike Acton, ex-Isomniac. He was talking about those fancy OO stuff, like Contracts/Abstract Classes/Incomplete Objects.
In my experience, I think it's important to worry about the communication between class and the outside code. It should be 1 that won't change if some optimization is made, so that it could stay only inside the class. i.e: free variables vs pack them into bits: the way of how the class will communicate should not change, saving lots of refactoring time. This kind of worry should be taken since the beginning.
It's as the same way as when reforming a building, workers stay only in the building, rather than getting out, hunting mentions of the build throughout the city.
Well, a lot of the times you don’t even have the time to test without those evil premature optimizations, and untested code is definitely the more evil one here…
„Premature optimization is the root of all evil” IS THE ROOT of all evil! Think about this my friend! 😉😎
It’s a cop-out people use when they can’t be bothered to take the time. In Unreal Engine people use similar reasoning to excuse themselves for right dirty, nasty, extremely disorganized, and performance heavy code
Optimization in my opinion does not necessarily need to mean the aspect of performance. Sometimes it is better to invest in the optimization of the architecture 😉
What does that even mean? I'm assuming you mean make it "cleaner", but by what metric? What score can you assign that measures how "good" an architecture is. With space and speed there are very clear metrics. I think I understand what you're trying to say, but I wholeheartedly disagree with your terminology.
Premature micro-optimisation is the root of all evil. Premature architectural or structural optimisation is not. Many things are very hard to optimise later if they haven’t been architected for efficiency, for example much of the data oriented techniques can be awkward or hard to retrofit. Multi threading is for sure simpler if you design for it to begin with. Using the correct data structures (and their implementations, eg std::map vs flat_hash_map) is easier before you’ve written a ton of code (some things are a drop in or near drop in replacement and some things are not).