3 ms·
I liked the idea behind this post, but really the author fairly widely missed the mark in my opinion. The extent to which you can "fool the optimizer" is highl
by Scubabear68 11mo ago
I liked the idea behind this post, but really the author fairly widely missed the mark in my opinion.
The extent to which you can "fool the optimizer" is highly dependent on the language and the code you're talking about. Python is a great example of a language that is devilishly hard to optimize for precisely because of the language semantics. C and C++ are entirely different examples with entirely different optimization issues, usually which have to do with pointers and references and what the compiler is allowed to infer.
The point? Don't just assume your compiler will magically make all your performance issues go away and produce optimal code. Maybe it will, maybe it won't.
As always, the main performance lessons should always be "1) Don't prematurely optimize", and "2) If you see perf issues, run profilers to try to definitively nail where the perf issue is".
- gpderetta 11mo agoI think the author is strictly talking about C and C++. Python is famously pessimal in all possible ways.
- Scubabear68 11mo agoDigging around, OK that makes sense. But even in the context of C and C++, there are often more ways the compiler can't help you than ways it can. The most common are on function calls involving array operations and pointers, but a lot of it has to do with the C/C++ header and linker setup as well. C and C++ authors should not blithely assume the compiler is doing an awesome job, and in my experience, they don't.
- gpderetta 11mo ago> C and C++ authors should not blithely assume the compiler is doing an awesome job Agree. And I'm sure the author agrees as well. That's why compiler-explorer exists in the first place.