3 ms·
I like Casey Miratory's "non-pessimization" approach in Philosophies of Optimization [1] [2]. He breaks "making a program go faster" into 3 modes: (1) "optimiz
by infogulch 4y ago
I like Casey Miratory's "non-pessimization" approach in Philosophies of Optimization [1] [2].
He breaks "making a program go faster" into 3 modes: (1) "optimization" which includes counting expected cycles or memory bandwidth, careful benchmarking, designing custom algorithms, etc which can be fun but is expensive and is only rarely applied; (2) "non-pessimization" which is simply avoiding adding extra unnecessary work for the cpu, which should be done 100% of the time but isn't in the industry today; (3) and "fake optimization" which is shallowly repeating 'optimization tips' and conclusions from unrelated cases of (1) without actually measuring it.
[1]: https://www.youtube.com/watch?v=pgoetgxecw8 https://www.youtube.com/watch?v=pgoetgxecw8
[2]: https://www.youtube.com/watch?v=lStYLF6Us_Q https://www.youtube.com/watch?v=lStYLF6Us_Q
- neonsunset 4y agoThank you for the links, looks like something definitely worth checking out, especially the name of the whole series "Simple Code, High Performance" because it sounds like the core of my approach to writing code. "non-pessimization" is my most loved technique because a design reduced to the minimum amount of necessary work and abstractions is more often than not has better performance and is easier to reason about.
- infogulch 4y agoThe whole series is pretty great. One of the interesting points he makes is that non-pessimization (2) is a necessary precondition to optimization (1). That any attempt to do hardcore optimization of a pessimized codebase is futile and will continuously faceplant into endless expanses of stupid code filled with unnecessary work for the cpu that instantly becomes the bottleneck.