I decided to test the effect of compiler optimization options in practice. There are two files (code2.cpp code3.cpp) with the same code.

#include <iostream> void printer(const int i){ std::cout << i << std::endl; } int main(){ for(int i = 0; i < 100; ++i) printer(i); return 0; }

I want to see the assembly code in two different cases. The first case is the use of a compiler with such options g ++ -S -O2 code2.cpp. And the second case is g ++ -S -O3 code3.cpp. As a result, I expected that the file that will be obtained from the use of the -O3 option will be more, because there will be a scan of the cycle.

The results were as follows (the file with the name 2 is what came out of code2.cpp, 3 of * 3.cpp)

 26/05/2018 10:37 169 code2.cpp 26/05/2018 11:30 3,865 code2.s 26/05/2018 10:34 169 code3.cpp 26/05/2018 11:30 3,865 code3.s 4 файлов 8,068 байт 2 папок 158,534,213,632 байт свободно

Those. the cycle did not turn around, but I really wanted to) What did I do wrong?

  • one
    Because the -o parameter sets the name of the output file (which is why files 2 and 3 turned out). And you didn’t use optimization at all, it is turned on with the -O key (capital O) - Mike
  • Thank. Changing the case of options has changed the definition of the file. Now everything is as it should be with regards to formats. But optimization still didn't work) (changed the question) - Semerkin
  • I do not know why you have such results. I have your example on O2 and O3 gives completely different results. Of course, there is no loop unfolding, because no compiler will ever think to unroll a loop of 100 iterations - Mike
  • My O3 just inserted the entire contents of the printer directly into the loop, which is clearly more profitable than deploying the loop and doing several call functions in a row - Mike
  • The compiler did not unfold the cycle, although I asked him about it using the option (as I understand it, the option is a guide to action, not as a recommendation (as with the inline keyword for a function)) - Semerkin

0