Optimization executables with gcc

Home> Programming> Optimization executables with gcc

Optimization executables with gcc

Escrever um comentário Ver comentários 25, January, 2009 VonNaturAustreVe Write a comment View comments

Optimization executables with gcc, explanations and definitions.

Recently a friend asked me "how do I make a faster executable on Linux," that intrigued me, did not know much about it then got to do more research on the optimization of executable, I found a lot of information is will present it in a tutorial, to become clearer.

The GCC compiler is the best there is (without any doubt), it consists of build tools, assembler and linker, its function is to produce executable ready to stop "running" in a format accepted by the OS (forms of execution is structure of a torque vary with the OS), its mode of operation is divided into 4 (four) steps, usually performed in sequence and automatically by the compiler:

Preprocessing: this step is the production of code that no longer has a policy, things like "# if" can not be understood directly by the compiler, therefore, be translated into machine code.

Compilation: step in the compiler translates the program text to a file object, which contains all references to codes and libraries used.
Assembler: Accepts the assembly mnemonics is produces code containing opcodes.É common misconceptions caused by the compiler, and not produce the opcodes, the stage of assembly "clean dirt" because the compiler.
Linking: name adapted from the English, linking, which transforms an object file executable, filling all the references and generating the complete code.

Now that we know a little more about the functioning of the GCC (I recommend the good old man gcc for more information), go to oque interests, the optimizations of the executable.

Note: It is important to check your version of gcc, because not all flags gcc 3.x work on gcc 2.x, so it's important to know the flags that your version of gcc support.

To know the version of GCC, type:

  $ Gcc - version gcc-v or

To find information about the processor:

  $ Cat / proc / cpuinfo

Now with the information about the processor is the version of gcc can continue.

What are CFLAGS?

CFLAGS are C compiler flags, usually options for GCC (GNU Compiler Collection). CFLAGS can be used to customize and optimize applications when you build them by sources. (This is an important feature of some distributions like gentoo, since most packages are installed from the source code there). CFLAGS are commonly used to specify the architecture of your computer and the type of CPU used and any other special option that you want to enable or disable. This information is important for the GCC tells him exactly how to customize the assembly instructions that it creates through the source code of the application. Technically, the GCC can run without any CFLAGS, since they are optional extras.

Optimizations Basic (safe)

There are several basic optimization options considered safe for general use. The first is-O (letter not number). To see exactly what optimization flags are enabled for each of the levels of optimization, as well as a list of other optimizations that can be enabled, please read the man page of GCC.

Him

-The league some basic optimizations that do not impact heavily on the speed of compilation, and will considerably increase the speed of your system. Although there is not much reason to use-O instead of-O2.

-O2

League all-O2 optimizations-O and all the other optimizations that greatly increase the size of the binaries generated or interfere with debugging. -O2 is even better than-O, and usually about as safe. This is the level of optimization used for most packages and distributions in the Linux world and for the Linux kernel. If you want a system that "just works",-O2 is probably good for you.

-O3

O3-league all-O2 optimizations and also some optimizations that increase the size of the generated binary as well as making debugging more difficult or even impossible. Using O3 as has default level of optimization can be a bad idea.

-O3 is the optimization level higher and possibly become the fastest code but the applications that benefit from this are very few, usually decoders and video image and the like. Entertaining, side effects, such as bigger binaries affect everything. Binary greater take up more memory, load slower, cause more I / O disk, etc.. Then build a system with-O3 will have the effect of a few applications running slightly faster than the cost of the rest of the system running slightly slower and becoming less responsive.

Linux holds regular programs and files in RAM (this is the "cache" when you run free-m), then programs may need to load the hard disk only once (depending on the program and computer used). So this is less a problem on systems with large amounts of RAM. A system with large amounts of CPU cache also helps because it fits better the bigger binaries, then you just noticing them more speed. So if you have a system up-to-line, you will suffer less from problems associated with-O3.

-The

-Os optimizes for size. -Os enables all-O2 optimizations that do not generally increase the size of the code and performs further optimizations designed to reduce the size of the code.

-Os is very useful for large applications, such as Firefox, KDE, openoffice, as it will reduce loading time, memory usage, cache, disk usage etc.. Code compiled with-Os can be faster than with-O2 or-O3 for it. It is also recommended for old computers with low RAM, disk space or CPU cache. But be warned that the not-so-well tested as O2 and can lead to bugs build.

Note that only one of the flags above can be chosen. If you choose more than one, only the last one specified takes effect.

-fomit-frame-pointer

-fomit-frame-pointer tells gcc to omit frame pointers, freeing an additional register in the CPU. This is especially useful on x86 as most of the architectures such as AMD64, it is by default at-O2 and above, although the size of the binary might increase slightly. This flag breaks debugging on x86 and possibly other architectures unless you compile with gcc 4.x and flag-fvar-tracking.

Glibc has a flag USE: glibc-omitfp. This makes use glibc-fomit-frame-pointer and some other enhancements to the package when it is safe. To read more about optimizing glibc try this HOWTO

-march = <your_architecture>

dis-march gcc to optimize for a certain architecture. Basically, you just need to know what your CPU, and the GCC code for it. Remember that this flag breaks compatibility with other architectures!

This flag takes the following form:

  -march = pentium4

Obviously you replace the code for pentium4.

Here is an incomplete list of valid x86 architectures that can be used with the flag-march:

i386, i486, i586, i686, pentium, pentium-mmx, pentiumpro, Pentium2, pentium3, pentium-m, pentium4, prescott, k6, k6-2, k6-3, k8, athlon, athlon-tbird, athlon-4, athlon-xp, athlon-mp, Athlon64, Opteron, WinCHIP-c6, winchip2, c3.

If you are using gcc 4.2 is easier and probably (if you do not know what the most appropriate flag) use:

-march = native

With that gcc will auto-detect

Check the gcc manual for a complete list (in Hardware Models and Configurations).

Note: "-march" implies "-mtune" (see man page of gcc).

-mtune = /-mcpu = <your_architecture>

-mtune,-mcpu or in older versions of GCC, is similar to the-march and accepts the same options. Unlike-march Compatibilidde it does not break other architectures. The options-march and -mtune/-mcpu can be mixed to achieve the desired effect. If you will not share your binaries with other computers you do not need this flag and must use only a flag-march proper. The exceptions are architectures like PPC where-march is not available. See the Guide to Safe CFLAGS for more information.

Documentation on GCC-march and -mcpu/-mtune

pipe

The last and most common flag is the '-pipe'. The pipe option tells GCC not to create temporary files when compiling, and instead channel (pipe) data directly to the next function, which saves some time to build. Be warned that using-pipe will make GCC use more RAM then do not use this if you are running low.

CFLAGS common for developers

-Wall: This enables all the warnings about constructions that some users consider questionable, and that are easy to avoid (or modify to prevent the warning), even in conjunction with macros.
-Wextra: Print extra warning
-Werror: Turns warnings on errors, and then the GCC will stop compiling after the warning (because it has an error).
-ggdb: Includes all the debugging information as possible in the resulting binary that is useful for gdb.