Talk:Optimizing

Where to optimise

Two things:

• I'm totally missing the bit on the algorithmic complexity thing compared to make the processor do as much at possible in a clock - If you can improve the complexity of an algorithm to something better the improvements are vastly more significant than when you optimise for occupying every processing unit.
• There's currently a bit on the execution architecture of the Pentium 1 - which is for current standards pretty much in-order architecture. Modern processors have several (IIRC, netburst had 5) execution ports, which gets assigned an instruction (or uop) and start working on them. The result is that P1 optimisation isn't necessarily good optimisation for later architectures. It might be a better idea to explain things more general (AGI stalls, Partial register stalls, register renaming, dependency breaking/delaying, loop blocking) as techniques to get more out of the average case - breaking dependencies will help on all superscalar architectures, and the current UV-optimisation example is just one special case for that, but not necessarily best for later processors.

- Combuster 21:47, 18 November 2008 (UTC)

Also on the high level there's simple tricks as function inlining (can be good for small functions), which takes away the overhead of the call. It should indeed be done for (inline) assembly functions, but might benefit other areas too like a linked list implementation. And what about compilers like clang that can perform Link Time Optimizations? GCC doesn't necessarily set the standard of optimizations. - Walling 13:33, 19 November 2008 (UTC)

Compiler Optimisations

"One thing to be aware of when using compiler optimizations is that when overdone (or even done at all) they can cause previously functioning code to become buggy, or not work at all."

I have a problem with that. If enabling a compiler optimization results in your code malfunctioning, your code was already broken beforehand, you just didn't realize it. volatile is not a patch around buggy compilers, it's an error when you don't set it where necessary. -- Solar 10:36, 18 November 2008 (UTC)

That's a good point. When I was thinking up that sentence though, I was thinking of bugs in the compiler (not many, but they do exist). But your scenario is much more likely. Jackscott 10:42, 18 November 2008 (UTC)

Fixed. Jackscott 07:28, 20 November 2008 (UTC)

Usually the optimizing code path of the compiler is even better tested than the non-optimizing one, because it's more often used... ;-) Solar 16:34, 12 January 2009 (UTC)