GCC optimization/es

Esta guía ofrece una introducción al código compilado de forma óptima usando CFLAGS y CXXFLAGS seguras y sanas. También describe la teoría detrás de la optimización en general.

¿Qué son CFLAGS y CXXFLAGS?
CFLAGS and CXXFLAGS are environment variables that are used to tell the GNU Compiler Collection (GCC) what kinds of switches to use when compiling source code. The CFLAGS variable is used for compiling code written in C, while the CXXFLAGS variable is for code written in C++.

Pueden usarse para disminuir la cantidad de mensajes de depuración de un programa, aumentar los niveles de aviso de errores, y por supuesto, optimizar el código producido. El manualde GCC ofrece una lista completa opciones disponibles y sus aplicaciones.

¿Cómo se utilizan?
CFLAGS and CXXFLAGS can be used in two ways. First, they can be used per-program with Makefiles generated by the program.

However, this should not be done when installing packages found in the Portage tree. Instead, for Gentoo-based machines, set the CFLAGS and CXXFLAGS variables in This way all packages will be compiled using the options specified in

As seen in the example above the CXXFLAGS variable is set to use all the options present in CFLAGS. Most every system should be configured in this manner; additional options for CXXFLAGS are extremely rare in common use cases.

Confusiones
While CFLAGS and CXXFLAGS can be very effective means of getting source code to produce smaller and/or faster binaries, they can also impair the function of the code, bloat its size, slow down its execution time. Setting them incorrectly can even cause compilation failures!

CFLAGS are not a magic bullet; they will not automatically make the system run faster or reduce the size of binaries on the disk. Adding too many flags in an attempt to optimize (or "rice") the system is a sure recipe for failure. The point of diminishing returns is reached rather quickly when dealing with CFLAGS.

Despite the boasts and brags found on the internet, aggressive CFLAGS and CXXFLAGS are far more likely to harm binaries than to do any good. Keep in mind the flags are designed to be used at specific places for specific purposes. Few flags work as intended globally.

¿Preparado?
Being aware of the risks involved, take a look at some sane, safe optimizations. These will hold in good stead and will be endearing to developers the next time a problem is reported on Bugzilla. (Developers will usually request the user to recompile a package with minimal CFLAGS to see if the problem persists. Remember: aggressive flags can ruin code!)

Conceptos básicos
The goal behind CFLAGS and CXXFLAGS is to create code tailor-made to your system; it should function perfectly while being lean and fast, if possible. Sometimes these conditions are mutually exclusive, so this guide will stick to combinations known to work well. Ideally, they are the best available for any CPU architecture. For informational purposes, aggressive flag use will be covered later. Not every option listed on the GCC manual (there are hundreds) will be discussed, but basic, most common flags will be reviewed.

-march
La primera y más importante opción es. Esta le dice al compilador que código debería producir para su arquitectura de procesador (o arch), le indica a GCC que debería producir código para un cierto tipo de CPU. Diferentes CPUs tienen diferentes características, soportan diferentes conjunto de instrucciones y tienen diferentes formas de ejecutar código. La opción  indicará al compilador que produzca código específico para la CPU del sistema, tomando en cuenta todas sus capacidades, características, conjuntos de instrucciones, caprichos y demás.

A pesar que la variable  en  especifica la arquitectura general utilizada,   también se usa para que los programas se optimicen para el procesador específico del sistema. Las arquitecturas x86 y x86-64 (entre otras) también deberían utilizar la opción.

¿Qué tipo de CPU tiene el sistema? Para averiguarlo, ejecute la siguiente orden:

Para obtener más detalles, incluyendo valores  y , utilice:

Ahora veamos a  en acción. Este ejemplo es para un antiguo Pentium III:

Aquí hay otro para una CPU AMD de 64 bits:

Si no se puede determinar el tipo de CPU o si e usuario no sabe que ajustes elegir, es posible utilizar el ajuste. Al usarla, GCC intentará detectar el procesador y automáticamente usará las opciones apropiadas. ¡Sin embargo, no se debe utilizar esto si se quiere compilar paquetes para CPUs diferentes!

Si se está compilando paquetes en una computadora, para ejecutarlos en una computadora diferente (usando, por ejemplo, una computadora rápida para construir paquetes para una máquina más antigua y lenta), entonces no utilice la opción. La palabra "native" significa que el código producido podrá ejecutarse solamente en ese tipo de CPU. Las aplicaciones construidas con  en una CPU AMD Athlon 64 CPU no podrán ejecutarse en una CPU VIA C3 más antigua.

También están disponibles las opciones  y. Cada una de ellas solo se usará cuando no haya otra opción  disponible. Ciertas arquitecturas de procesador pueden requerir  o incluso de. Desgraciadamente, el comportamiento de GCC no es muy consistente con la manera que cada opción se comporta de una arquitectura a otra.

En CPUs x86 y x86-64,  se generará código específico para esa CPU usando sus instrucciones disponibles y el ABI correcto; no tendrá compatibilidad hacia atrás para CPUs antiguas o diferentes. Se puede considerar el uso de  cuando se genere código para CPUs antiguas como i386 e i486. produce un código más genérico que ; aunque afinará el código para cierta CPU, no se tendrán en cuenta los conjuntos de instrucciones disponibles y ABI. No utilice la opción  en sistemas x86 o x86-64, ya que es obsoleto para estas arquitecturas.

Solo las CPUs que no sean x86/x86-64 (como Sparc, Alpha y PowerPC) pueden requerir  o   en lugar de. En estas arquitecturas, /  algunas veces se comportará como   en (x86/x86-64)... pero con un nombre distinto. De nuevo, el comportamiento de GCC y los nombres de las opciones no son consistentes entre arquitecturas, así que asegúrese de revisar el manual de GCC para determinar cual de ellas se debería utilizar.

-O
Hablaremos ahora de la variable. Esta variabe controla el nivel de optimización de todo el código. Al cambiar este valor, la compilación de código tomará algo más de tiempo, y utilizará mucha más memoria, especialmente al incrementar el nivel de optimización.

Existen siete ajustes para : ,  ,  ,  ,  ,   y. Se debe utilizar solo uno de ellos en.

A excepción de, la configuración de   activa varias opciones adicionales, así que asegúrese de leer el capítulo del manual de gcc enopciones de optimización para aprender qué opciones se activan en cada nivel  , así como algunas explicaciones sobre lo que hacen.

Examinemos cada nivel de optimización:


 * : This level (that is the letter "O" followed by a zero) turns off optimization entirely and is the default if no  level is specified in CFLAGS or CXXFLAGS . This reduces compilation time and can improve debugging info, but some applications will not work properly without optimization enabled. This option is not recommended except for debugging purposes.


 * : El nivel de optimización más básico. El compilador intentará producir un código rápido y pequeño sin tomar mucho tiempo de compilación. Es básico, pero conseguirá realizar correctamente el trabajo.


 * : Un paso delante de . Es el nivel recomendado de optimización, a no ser que el sistema tenga necesidades especiales.   activará algunas opciones añadidas a las que se activan con  . Con , el compilador intentará aumentar el rendimiento del código sin comprometer el tamaño y sin tomar mucho más tiempo de compilación.


 * : El nivel más alto de optimización posible. Activa opitimizaciones que son caras en términos de tiempo de compilación y uso de memoria. El hecho de compilar con  no garantiza una forma de mejorar el rendimiento y, de hecho, en muchos casos puede ralentizar un sistema debido al uso de binarios de gran tamaño y mucho uso de la memoria. También se sabe que   puede romper algunos paquetes. No se recomienda utilizar.


 * : Optimizará el tamaño del código. Activa todas las opciones de  que no incrementan el tamaño del código generado. Es útil para máquinas con capacidad limitada de disco o con CPUs que tienen poca caché.


 * : En GCC 4.8 aparece un nuevo nivel del optimización general: . Trata de solucionar la necesidad de realizar compilaciones más rápidas y obtener una experiencia superior en la depuración a la vez que ofrece un nivel razonable de rendimiento en la ejecución. La experiencia global en el desarrollo debería ser mejor que para el nivel de optimización  . Observe que   no implica , éste simplemente deshabilita optimizaciones que podrían interferir con la depuración.


 * : Nuevo en GCC 4.7. Consiste en el ajuste  más las opciones ,   y  . Esta opción rompe el cumplimiento de estándares estrictos y no se recomienda su utilización.

As previously mentioned,  is the recommended optimization level. If package compilation fails and while not using, try rebuilding with that option. As a fallback option, try setting the CFLAGS and CXXFLAGS to a lower optimization level, such as  or even   (for error reporting and checking for possible problems).

-pipe
Una opción común es. No tiene efecto sobre el código que se produce, pero hace que el proceso de compilación sea más rápido. Indica al compilador que use tuberías en lugar de archivos temporales durante los diferentes estados de compilación, lo cual usa más memoria. En sistemas con poca memoria, el proceso GCC se podría terminar por el sistema En estos casos no se debe utilizar esta opción.

-fomit-frame-pointer
Esta es una opción muy común diseñada para reducir el tamaño del código generado. Está activada para todos los niveles de  (excepto  ) en arquitecturas donde no interfiera con la depuración (como x86-64), pero puede que haga falta activarla. En ese caso, se debe añadir a las opciones. Aunque el manual de GCC no especifica todas las arquitecturas, se activa mediante la opción. Todavía es necesario habilitar explícitamente la opción. Para activarla en una arquitectura x86-32 con GCC hasta la versión 4.6 o cuando se utilice  en x86-32 con cualquier versión de GCC. Sin embargo, al usar  la depuración será algo difícil o incluso resultará imposible.

In particular, it makes troubleshooting applications written in Java much harder, though Java is not the only code affected by using this flag. So while the flag can help, it also makes debugging harder; backtraces in particular will be useless. When not doing software debugging and no other debugging-related CFLAGS such as  have been used, then try using.

-msse, -msse2, -msse3, -mmmx, -m3dnow
Estas opciones activan los conjuntos de instrucciones Streaming SIMD Extensions (SSE), SSE2, SSE3, MMX y [http://es.wikipedia.org/wiki/3DNow! 3DNow!] para arquitecturas x86-64. Son útiles principalmente en multimedia, juegos y otras tareas intensivas de computación en punto flotante, aunque también contienen muchos otros realces matemáticos. Estos conjuntos de instrucciones se encuentran en las CPUs más modernas.

Normalmente no se necesita añadir ninguna de estas opciones a mientras el sistema esté utilizando la   correcta (por ejemplo,   implica  ). Algunas excepciones notables son las nuevas CPUs VIA y AMD64 que soportan instrucciones no implicadas por  (como SSE3). Para CPUs como estas, se necesita habilitar opciones adicionales donde sea necesario después de verificar la salida de.

Sin embargo, ¡Consigo mejor rendimiento con -funroll-loops -fomg-optimize!
No, solo piensa que lo hace porque alguien le ha convencido que es mejor utilizar el mayor número de opciones. Las opciones agresivas solo dañarán las aplicaciones cuando use un sistema completo. Incluso el manual de GCC dice que usar  y   hará que el código ocupe más espacio y que corre más lento. Aunque por alguna razón, estas dos opciones, junto con,  ,  , y similares, continúan siendo muy populares entre pardillos que creen saber más que nadie.

La verdad es que son opciones peligrosamente agresivas. Eche un vistazo a los Foros de Gentoo y a Bugzilla para ver que hacen estas variables: ¡Nada bueno!

You do not need to use those flags globally in CFLAGS or CXXFLAGS. They will only hurt performance. They may make you sound like you have a high-performance system running on the bleeding edge, but they don't do anything but bloat the code and get your bugs marked INVALID or WONTFIX.

No necesita opciones peligrosas como estas. '''No las utilice'''. Quédese con las básicas:,   y.

¿Qué pasa con los niveles -O mayores que 3
Some users boast about even better performance obtained by using,  , and so on, but the reality is that   levels higher than 3 have no effect. The compiler may accept CFLAGS like, but it actually doesn't do anything with them. It only performs the optimizations for, nothing more.

¿Necesita más pruebas? Eche un vistazo al código fuente:

Como puede observar, cualquier valor mayor que 3 se trata como.

¿Qué ocurre cuando compilamos fuera de la máquina destino?
Algunos lectores se pueden preguntar si el hecho de compilar fuera de la máquina destino usando una CPU estrictamente inferior o una subarquitectura en GCC generará unos resultados de optimización inferiores. La respuesta es simple: No. Independientemente del hardware en el que realmente se realiza la compilación y el CHOST con el que se construyó GCC, si se utilizan los mismos argumentos (excepto para ) y la misma versión de GCC (aunque la versión menor puede ser distinta), las optimizaciones resultantes son estrictamente las mismas.

Como ejemplo, si Gentoo se instala en una máquina en el que el CHOST de GCC es i686-pc-linux-gnu, y se utiliza un servidor Distcc/es en otro equipo en el que el CHOST de GCC es i486-linux-gnu entonces no hay porqué preocuparse de que los resultados sean menos óptimos ya que la subarquitectura del compilador o el hardware del equipo remoto son estrictamente inferiores. El resultado sería igual de óptimo que una construcción en una máquina nativa siempre que se pasen las mismas opciones a ambos compiladores (y no se defina el argumento  como  ). En este caso en particular se necesita especificar la aquitectura destinotal y como se indica en Distcc y -march=native.

La única diferencia en el comportamiento entre dos versiones de GCC construidas con diferentes subarquitecturas es el valor implícito por defecto para el parámetro  que se deriva del CHOST de GCC cuando no se ha indicado uno de forma explícita en la línea de órdenes.

¿Qué pasa con las opciones redundantes?
Oftentimes CFLAGS and CXXFLAGS that are turned on at various  levels are specified redundantly in. Sometimes this is done out of ignorance, but it is also done to avoid flag filtering or flag replacing.

Flag filtering/replacing is done in many of the ebuilds in the Portage tree. It is usually done because packages fail to compile at certain  levels, or when the source code is too sensitive for any additional flags to be used. The ebuild will either filter out some or all CFLAGS and CXXFLAGS, or it may replace  with a different level.

El Manual del Desarrollador de Gentoo indica dónde y cómo funciona el filtrado y el reemplazo de opciones.

Es posible evitar el filtrado de  filtrando mediante el listado redundante de opciones para un cierto nivel, como , haciendo cosas como:

However, this is not a smart thing to do. CFLAGS are filtered for a reason! When flags are filtered, it means that it is unsafe to build a package with those flags. Clearly, it is not safe to compile your whole system with  if some of the flags turned on by that level will cause problems with certain packages. Therefore, you shouldn't try to "outsmart" the developers who maintain those packages. Trust the developers. Flag filtering and replacing is done for your benefit! If an ebuild specifies alternative flags, then don't try to get around it.

No encontrará más que problemas cuando construya un paquete con opciones inaceptables. Cuando informe de sus problemas en Bugzilla, las opciones que usó en serán fácilmente visibles y se le instará a recompilar sin ellas. ¡Protéjase de los problemas de recompilar evitando el uso de opciones redundantes! No asuma automáticamente que sabe más que los desarrolladores.

¿Qué pasa con LDFLAGS?
The Gentoo developers have already set basic, safe LDFLAGS in the base profiles, so they do not need to be changed.

¿Puedo usar opciones para cada paquete?
Information on how to use per-package environment variables (including CFLAGS ) is described in the Gentoo Handbook, "Per-Package Environment Variables".

Recursos
Los siguientes recursos pueden ser de ayuda para comprender la optimización:


 * La documentación en línea de GCC


 * El capítulo 5 de los manuales de instalación de Gentoo


 * man make.conf


 * Wikipedia


 * Los Foros de Gentoo