2 ms·

> Also, compilers don't reason about code the same way humans do. They apply a large number of small transformations, each of these transformations is very reas

> Also, compilers don't reason about code the same way humans do. They apply a large number of small transformations, each of these transformations is very reasonable and it is their combination that results in "absurd" optimization results. So true. It baffles me how sometimes I hear colleagues of mine just "assuming" that the compiler will deal with something. Something that does require a really high level reasoning to come true. It's absurd.

somenameforme 3y ago
IMO it all comes down to the, 'Premature optimization is the root of all evil.' That saying was, at its best, not great. But it seems at some point down the road the 'premature' part of that sentence was lost to history and it became something much worse. It goes some way towards explaining why we now need machines that would be considered supercomputers, just a couple of decades prior, to run a text editor. Unreal Engine is a beautiful example of this. The source code of that engine is absolutely full of 'premature optimizations.' For instance repeatedly converting a Quaternion to a Rotator (Euler angles) is basically never going to get red-lined on a profiler, let alone be a bottleneck. Yet there's a caching class used in the engine for this exact purpose. It's all of these little 'premature optimizations' that end up creating a system that runs vastly better than most any other engine out there, feature for feature.
- mike_hock 3y ago
  It's a dogma pendulum like "gotos are evil," "YAGNI," object-oriented design (is good/bad), etc. A pattern or anti-pattern gets identified and lessons drawn from it. Then people take the lesson as dogma and drive it to absurd extremes. Naturally this doesn't have the desired effect, and then the baby gets thrown out with the bathwater, people do the exact opposite and take that to absurd extremes. Caching potentially expensive (relatively speaking) operations isn't "premature optimization," it's a design principle. It's much harder to retrofit something like this into a project after the fact than having and using it from the start. "Premature optimization" is applying complicated micro-optimizations early on that won't survive any moderate code change.
6D794163636F756 3y ago
It depends on the compiler really. C is nice is that you can choose a compiler fit for your purpose but it makes my next example harder to I'm going to discuss go. I was doing leetcode recently and one of the problems was to combine some set of sorted linked arrays into one bigger array. There are a few ways to do this but I ran two of them to see which was better. 1.) I select the lowest from the set of first elements in the arrays, add it to the end of my new list, then increment the iterator for that array. 2.) Dump all of them into one array then sort the new array entirely. Surprisingly the second option was faster and didn't have a higher memory cost. From what I could tell this was because it used fewer memory allocations, could run better optimizations, and the standard library in go has a good sorting algorithm. One of the greatest skills I think we can develop as programmers is knowing when to trust the compiler and when not to. All of this is to say I agree with you on principle but there is nuance and a degree to which we can trust the compiler, but only if we've chosen one that we are familiar with and that is well suited for the task at hand.
- almostnormal 3y ago
  Not necessarily just a matter of details of the assembly, but also of cache utilization.

somenameforme 3y ago

IMO it all comes down to the, 'Premature optimization is the root of all evil.' That saying was, at its best, not great. But it seems at some point down the road the 'premature' part of that sentence was lost to history and it became something much worse. It goes some way towards explaining why we now need machines that would be considered supercomputers, just a couple of decades prior, to run a text editor. Unreal Engine is a beautiful example of this. The source code of that engine is absolutely full of 'premature optimizations.' For instance repeatedly converting a Quaternion to a Rotator (Euler angles) is basically never going to get red-lined on a profiler, let alone be a bottleneck. Yet there's a caching class used in the engine for this exact purpose. It's all of these little 'premature optimizations' that end up creating a system that runs vastly better than most any other engine out there, feature for feature.

mike_hock 3y ago
It's a dogma pendulum like "gotos are evil," "YAGNI," object-oriented design (is good/bad), etc. A pattern or anti-pattern gets identified and lessons drawn from it. Then people take the lesson as dogma and drive it to absurd extremes. Naturally this doesn't have the desired effect, and then the baby gets thrown out with the bathwater, people do the exact opposite and take that to absurd extremes. Caching potentially expensive (relatively speaking) operations isn't "premature optimization," it's a design principle. It's much harder to retrofit something like this into a project after the fact than having and using it from the start. "Premature optimization" is applying complicated micro-optimizations early on that won't survive any moderate code change.

6D794163636F756 3y ago

It depends on the compiler really. C is nice is that you can choose a compiler fit for your purpose but it makes my next example harder to I'm going to discuss go. I was doing leetcode recently and one of the problems was to combine some set of sorted linked arrays into one bigger array. There are a few ways to do this but I ran two of them to see which was better. 1.) I select the lowest from the set of first elements in the arrays, add it to the end of my new list, then increment the iterator for that array. 2.) Dump all of them into one array then sort the new array entirely. Surprisingly the second option was faster and didn't have a higher memory cost. From what I could tell this was because it used fewer memory allocations, could run better optimizations, and the standard library in go has a good sorting algorithm. One of the greatest skills I think we can develop as programmers is knowing when to trust the compiler and when not to. All of this is to say I agree with you on principle but there is nuance and a degree to which we can trust the compiler, but only if we've chosen one that we are familiar with and that is well suited for the task at hand.

almostnormal 3y ago
Not necessarily just a matter of details of the assembly, but also of cache utilization.