What are the known C/C++ optimizations for GCC

Question

I am have a lot of code that I need to optimize and make it run faster. I used opreport to tell me where the code spends a lot of time. I use the following command to get the statistics

opreport -g -l -d

Suggestions to get better statistics are appreciated using different flags, perhaps find it per line number instead of function number.

So a lot of issues that I "think" I see are in regard to:

• pointers, multidimensional arrays
• multiplications
• loops

I want compiler to optimize the code better, thus helping him. I factored some code blocks into function with word restrict to tell compiler that my pointer arrays don't overlap.

SO I am I am looking for (a) common C constructs that can make code run longer and (b) how to help compiler optimize code.

Thanks

Answer 1

Here's a contentious argument -- if there are 'common C constructs that can make code run longer' (and I'm sure you are right to think that there are such constructs) then I would expect a good optimising compiler to, well, optimise for them. You don't reveal which compiler(s) you are using, and I'm not a C/C++ programmer, so it's difficult for me to suggest any particular compiler flags or tricks to try.

The only concrete advice I would offer is this: study the output of your profiling tool(s) very carefully and only spend your time optimising those parts of the program where it's worth the effort.

Answer 2

In my experience, it doesn't have much to do with what language or compiler you are using, and it has everything to do with how the code is designed and organized.

If you think only small optimizations are possible, and that it really depends on the compiler, you might find this surprising.

This is the method I use, and an explanation of why it works.

Answer 3

Memory allocation can be slow in C++. Make sure you are looping over your arrays properly for cache coherence. if you have int arr [100][1000] then you want to loop like

for(int i = 0; i < 100; i++) for(int j = 0; j < 1000; j++) arr[i][j]

If you loop over i after j then your CPU's cache isn't being used properly. If you are doing a large number of multiplies try to introduce temps to minimize the number of multiplies you do. The compiler should do common sub expression elimination but sometimes it helps to do it explicitly.

Answer 4

Well, there are two kinds/approaches to the optimization.
First, one can optimize the architecture. You know, binary search instead of the bubble one and so on :) But seriously, I hope this point is clear.
And the second, technical: one uses the profiler in any form and looks for the bottlenecks. Then, when bottlenecks are found, optimization is necessary only for them.

It is well known, that premature optimization is the root of the evil, so just don't care about minor tweaks like types/loops/virtuals-or-not/and so on. Mostly it is not so important while takes a lot of time. IMHO, the psychological impact is much higher here than the real one.
Also, you can talk to game developers: they are really professional in this and I guess that they would repeat my words: optimize only what is necessary to optimize and then optimize the architecture of the problematic block.
P.S. Also CPUs are different and your optimization can be just the waste of time for some of them...

Answer 5

Beware of the reports from profiling tools, they can be misleading. For instance, consider an application that does a large amount of string comparisons and not much else. A report is going to tell you that you spend >90% of your time in string comparison functions. So naturally, you decide to implement an optimized version of that code only find out that the profiler tells you that you are still spending 90% of your time there (because that is all your program does...).

You have to have intimate knowledge of your application and apply that to a profiler else you might be wasting effort.

Compilers today do a fairly good job of optimizing (especially with extra flags as options). It is unlikely that you will benefit from anything at a language level (i.e. how you handle arrays) - you will probably have to read/write asm if you want to hand tune things.

Answer 6

The biggest thing I know in C++ is to be careful about the methods that you call. In C++ (and any OO language) it's pretty trivial to hide a LOT of processing behind a very small interface.

This is especially important when dealing with overloaded operators - depending on the library these can be BIG time sinks, and look like nothing at all in the code.

Answer 7

In General: In my experience, 90% of the time repairing silly mistakes (like unintentionally copying instead of passing references) and tweaking algorithms and data structures is what makes significant differences. Thinking about low-level optimizations is only useful when you have fully done those 90%.

In your case: If opreport (which I don't know, BTW) told you where your application spends its time, you'll have to optimize those bits. If you need help with doing so, you might have to post somewhat concrete examples.