I HATE "premature optimization is the root of all evil" (sometimes)

Подписаться 662 тыс.

Просмотров 61 тыс.

50% 1

get.hazelengin...
cherno.live
Patreon ► / thecherno
Instagram ► / thecherno
Twitter ► / thecherno
Discord ► / discord
Hazel ► hazelengine.com
🕹️ Play our latest game FREE (made in Hazel!) ► studiocherno.i...
🌏 Need web hosting? ► hostinger.com/...
💰 Links to stuff I use:
⌨ Keyboard ► geni.us/T2J7
🐭 Mouse ► geni.us/BuY7
💻 Monitors ► geni.us/wZFSwSK

Опубликовано:

2 окт 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 95

@PhoenixOP001 6 месяцев назад

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

@Its.all.goodman 6 месяцев назад

Well said

@brawldude2656 5 месяцев назад

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

@zissler1 Месяц назад

I doubt that’s the case no matter how skilled on large projects.

@nobytes2 Месяц назад

People rarely know how to profile their programs hell half can barely use a debugger

@bryceblankinship 6 месяцев назад

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.

@jacobmars1902 6 месяцев назад

same as people misquoting “the blood of the covent is thicker than water of the womb” as “blood is thicker than water”

@barry5 5 месяцев назад

@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.

@AllanSavolainen 5 месяцев назад

I recall that the original version talked about premature optimization in assembler

@TheOriginalBlueKirby 3 месяца назад

So then how is it out of context? This added absolutely no context to it whatsoever.

@bryceblankinship 3 месяца назад

@@TheOriginalBlueKirby actually it did. Cherno said in his video that he doesn't like the quote because it doesn't address tangible differences in program speed. But the expanded quote is saying that we should "forget about small efficiencies". Generally good to follow the advice of Knuth over a youtuber (I learned a lot from Cherno over the years but he is no Knuth, and I am no Cherno), as Knuth has built some legendary programs throughout the years with very little bugs in them. Program execution speed means nothing if it doesn't work later in the application!

@abacaabaca8131 6 месяцев назад

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.

@ald5397 6 месяцев назад

Example of solution that can be solved by math?

@abacaabaca8131 5 месяцев назад

@@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.

@blarghblargh 3 месяца назад

@@ald5397 search for "branchless programming". both Creel and Inigo Quiliz have interesting videos on this sort of thing.

@Blazs120gl 6 месяцев назад

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.

@NihongoWakannai 3 месяца назад

Luckily for software engineering you dont have to worry about physical space and materials. So long as the public facing interface is the same you can do whatever you want under the hood.

@oracleoftroy 6 месяцев назад

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.

@sammyfromsydney 3 месяца назад

It's not premature if you know you need it.

@Zullfix 6 месяцев назад

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.

@neversimon 6 месяцев назад

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.

@Darkness_7193 6 месяцев назад

"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

@protonmaster76 5 месяцев назад

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.

@NihongoWakannai 3 месяца назад

Yeah, the main problem is really that it's meant for the intended audience of experienced programmers who are misusing their skill. Instead, new programmers hear it and think that it's fine for them to never worry about having optimized code. But a lot of optimizations can be done with almost zero extra time it just requires experience.

@iskamag 3 месяца назад

I'd rather use the first algorithms that come to mind and get the program done 10 times faster, only then rewrite for speed, which would take half the time.

@pokefreak2112 6 месяцев назад

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

@AgentM124 6 месяцев назад

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.

@ToothbrushMan 6 месяцев назад

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.

@KoltPenny 5 месяцев назад

The quote actually refers to what you said. People misuse it.

@an_wobbly 4 месяца назад

Pretty sure if you're capable and write optimized code the first try, then it's not quite premature is it?

@MrDasfried 2 месяца назад

What's premature about experience though? Like the Quote Talks about unenessary optimization and not about whtt you know to be proven/good technics and solutions...

@J.D-g8.1 3 месяца назад

With C++ you can get caught in the whole "if i just rewrite my for-loops to decrement from 100 to 0 instead of incrementing, this will be faster on 8 bit microcontrollers... and if i make that vector into an array with a helper function to access the data to avoid heap allocation... Wait, what was in writing again..? Oh right, its a ascii tic tac toe game!" And that is aside from the point that you dont necessarily know that your code is actually faster before you test it. But, of course it makes sense to write the code as good as you can. If not, then why not write the program first in f.ex Python, and then rewrite it in C++ afterwards? (Because it sucks to write Python, and it would be twice the work! But i mean - , something.something)

@blarghblargh 3 месяца назад

I like the quote when replaced with the word "generalization" instead of "optimization". Making code flexible has a cost in bugs, performance, and conceptual complexity. Programmers often fail to notice how little they get in return for their added flexibility, especially if they add it before they are putting it to good use. Indirection is a tool to solve a problem, and if you're adding it for problems that don't exist or are small, then you are adding a cost with little benefit. Do this all over a program, and you're going to cause a maintenance nightmare that is hard to review for bugs.

@tolkienfan1972 4 месяца назад

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.

@NeunEinser 3 месяца назад

I kind of half agree with the quote. Here is my take in it: Premature optimization is always bad. Being a skilled programmer means to have an understanding when an optimization is actually premature. You could say this for a lot of things though. Prematurely trying to implement features that take a lot of time to implement, while the customer actually doesn't want or need them is another one. Of course iterating and throwing things away is a good thing and needed, so again it takes skill to know what a reasonable time is to spend on certain implementations, and maybe if a simpler "proof of concept" kind of solution might be better, to be able to continue iterating sooner.

@mario7501 4 месяца назад

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.

@Tobsson 3 месяца назад

I don't optimize until it becomes a problem or if all the features are in place. Optimizing my code from the get go would, like really sitting and thinking about it, would stop my productivity all together.

@georgehelyar 3 месяца назад

Just focus on the big stuff first. Don't do a lot of unnecessary I/O etc. Don't worry about SIMD etc until you've profiled.

@timothyhoytbsme 4 месяца назад

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.

@ragnarok7976 3 месяца назад

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.

@psicommander 5 месяцев назад

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…

@VideoGameBoxReviews 4 месяца назад

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.

@senoraraton 4 месяца назад

Premature optimization to me is planned ng for future features that may or may not come, not optimizing the actual thing your working on.

@edsanville 4 месяца назад

So, in other words... use a profiler and know what your priorities are?

@michaelb4727 6 месяцев назад

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.)

@shulehr 2 месяца назад

sometimes you write some physics, and if you dont wanna wait 50 years for next frame you need optimization before you can test the simplest thing

@oscarfriberg7661 4 месяца назад

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.

@ZantierTasa Месяц назад

Write code that is simple, easy to read, easy to write. Only write more optimal code if you have more experience: you have experience with performance benchmarking, you understand the importance of cache locality, you know how your programming language lays out your variables in memory (stack vs heap, and whether the data is close together or not). Some people might be surprised that e.g. using a HashMap instead of a List, or using binary search instead of linear search might not always be as fast as you think it would be.

@Beatsbasteln 2 месяца назад

certainly. i optimize as hard as i can without making my code feel weird and hard to reason about

@williamweidner5425 4 месяца назад

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?

@coc235 Месяц назад

Premature optimization usually means small easy-to-make improvements to the parts of code that aren't usually impacting the performance much, e.g. using switch statements instead of if or creating your own hash set implementation because it might be faster than a list. Knowing and avoiding potential bottlenecks isn't premature optimization, it's called being smart.

@drizer4real 3 месяца назад

the customer (ie the entity/person(s)/party of interest ) should be at the heart of it. They pay/buy it. And they have zero patience for slow apps and applications. I mean Google Maps is a crime against humanity If it takes more then 10 seconds, most people tune out. So yes, optimize it like hell imho.

@oliver_twistor 2 месяца назад

I think people miss in that quote is that the word premature by definition implies too early. Premature optimisation isn't optimisation or even early optimisation; it's _too_ early optimisation, and that's by definition bad. So, with that said, I strongly believe that premature optimisation is always something one should avoid. At the same time, I also believe that one can save a lot of time and energy by doing reasonable optimisations while writing code, or perhaps better said, while designing the architecture and program flow.

@farpurple 3 месяца назад

Hmm if on optimization whole structure of your work depends, and it is saving minutes from processing time, definetly do, and maybe even 3x more time development is oay

@User948Z7Z-w7n 2 месяца назад

I think what that quote means is micro-optimization is most of the times worse than the default optimization (provided by compiler or interpreter) and we should focus on macro-optimization instead

@blarghblargh 3 месяца назад

it's always a tradeoff. what is learned with experience is how to weigh the tradeoff, instead of letting a rule make the decision for you. the right move for an intermediate beginner who doesn't know is to try both and figure out what the tangible differences even are. and the right move for a beginner is to not worry about it and just get it all working. finishing projects is the first and most important skill to learn, and there's time to experiment after it's done.

@florin-alexandrustanciu5643 2 месяца назад

No, I don t think experience has a part in that saying, the meaning of it is that you dont need to think about optimization in the beginning, when most of the time requirements are incomplete and will change, it does not say never think about optimization, think of it when you are sure what everything does

@JaDanBar97 Месяц назад

It would probably take me longer to write non-optimised code because I'm so used to optimizing code from the get go 😂

@JaDanBar97 Месяц назад

As you get better you will write naturally optimized code faster...

@kinershah464 3 месяца назад

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.

@orbatos 3 месяца назад

Oversimplifying approaches to anything is a bad idea, who knew?

@skipfred 2 месяца назад

You're missing the word "premature" in the phrase.

@jayabegglen4665 2 месяца назад

But my gf said it was just regular optimization.

@AJSquirrel53 6 месяцев назад

The quote is about code "cleanliness", not initial performance

@SeanJMay 6 месяцев назад

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.

@abba_m_ 6 месяцев назад

If you're experienced enough to write optimized code out of the box, I don't think that qualifies as premature optimization.

@natescode 6 месяцев назад

Exactly.

@gniludio 6 месяцев назад

Next time I will permutate a list until its sorted. Maybe some thoughts about optimization don't hurt.

@shavais33 5 месяцев назад

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.

@SergeyBerengard 6 месяцев назад

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.

@sebastiencourtois8696 6 месяцев назад

Premature caching is, indeed

@Andeijogando 6 месяцев назад

I like that quote

@susu5331 6 месяцев назад

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…

@F1nalspace 6 месяцев назад

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.

@lainiwakura3741 6 месяцев назад

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.

@F1nalspace 6 месяцев назад

@@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.

@lainiwakura3741 6 месяцев назад

@@F1nalspace Thanks for the tip, I'll check it out

@MrAbrazildo 6 месяцев назад

_"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.

@vast634 6 месяцев назад

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.

@KamiKomplex504 6 месяцев назад

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.

@GenericInternetter 6 месяцев назад

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".

@hanspeterbestandig2054 6 месяцев назад

„Premature optimization is the root of all evil” IS THE ROOT of all evil! Think about this my friend! 😉😎

@Принуждениекмиру-ь2ц 4 месяца назад

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.

@WoodySTP 6 месяцев назад

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.

@SeanJMay 6 месяцев назад

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.

@hanspeterbestandig2054 6 месяцев назад

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 😉

@cyberchef8344 6 месяцев назад

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.

@JohnConnor-pz9xz 6 месяцев назад

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

@guywithknife 5 месяцев назад

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).