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 y CXXFLAGS son variables de entorno usadas para indicar a la Colección de Compiladores de GNU,, qué tipo de parámetros usar cuando compila código fuente. Las CFLAGS se aplican al código escrito en C, mientras que CXXFLAGS son para código escrito en 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 y CXXFLAGS se pueden usar de dos formas. La primera, por programa con los ficheros Makefile generados por automake.

Sin embargo, esto no debería hacerse cuando instalamos paquetes que se encuentran en el árbol Portage. En su lugar, establezca sus CFLAGS y CXXFLAGS en. De esta manera todos los paquetes se compilarán con las opciones que especifique.

CFLAGS en /etc/portage/make.conf

Como puede ver, CXXFLAGS se establece para usar todas las opciones presentes en CFLAGS. Casi seguro que es lo que se desea. Normalmente no necesitará especificar opciones adicionales en CXXFLAGS.

Confusiones
Aunque CFLAGS y CXXFLAGS pueden ser muy efectivos tomando el código fuente para producir binarios pequeños o rápidos, también pueden deteriorar la función de su código, inflar su tamaño, ralentizar su ejecución, ¡O incluso causar errores de compilación!

CFLAGS no es una solución mágica; no hará que su sistema corra más rápido o sus binarios sean más pequeños automáticamente. Añadir más y más parámetros en un intento de optimización (o "apretar") su sistema es una receta segura para fracasar. Hay un punto en el cual alcanzará resultados de peor calidad.

A pesar de las recomendaciones que se pueden encontrar en Internet, unas variables CFLAGS y CXXFLAGS agresivas están más cerca de dañar sus programas que de hacerles algún bien. Recuerde que la razón para la cual existen los parámetros en primer lugar es porque están diseñadas para usarse en sitios específicos para propósitos específicos. ¡Solo porque una CFLAG particular sea buena para un fragmento de código no significa que esté diseñada para compilar todo lo que quiera instalar en su máquina!

¿Preparado?
Ahora que le hemos advertido de algunos de los riesgos involucrados, echemos un vistazo a algunas optimizaciones sanas y seguras para su computadora. Esto le será útil y los desarrolladores lo agradecerán la próxima vez que informe de un problema en Bugzilla. (Los desarrolladores suelen pedir que recompile un paquete con los CFLAGS mínimos para ver si el problema persiste. Recuerde que los parámetros agresivos pueden arruinar el código.)

Conceptos básicos
El objetivo de usar CFLAGS y CXXFLAGS es crear código específico para su sistema; debería funcionar perfectamente y ser ligero y rápido, si es posible. Algunas veces estás condiciones son mutuamente excluyentes, pero nosotros trabajaremos con combinaciones que sabemos que funcionan bien. Idealmente, las mejores están disponibles para cada arquitectura de CPU. Mencionaremos más adelante ajustes más agresivos para que se sepa con cuales debe tener cuidado. No discutiremos cada opción listada en el manual de  (hay cientos), pero hablaremos de las básicas, las más comunes.

-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); dice 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 su CPU, tomando en cuenta todas sus capacidades, características, conjuntos de instrucciones, caprichos y demás.

A pesar que la variable CHOST en especifica la arquitectura general utilizada,   también se usa para que sus programas sean optimizados para su procesador específico. Las arquitecturas x86 y x86-64 (entre otras) también deberían utilizar la opción.

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

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

/etc/portage/make.conf: Pentium III

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

/etc/portage/make.conf: AMD64

Si todavía no está seguro qué tipo de CPU tiene, tal vez quiera usar la opción. Al usarla, GCC detectará el procesador y automáticamente usará las opciones apropiadas. ¡Sin embargo, no use esta opción si la intención es ¡compilar paquetes para un CPU diferente!

De manera que, si está compilando paquetes en una computadora, pero piensa 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  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 todas sus instrucciones disponibles y el ABI correcto; no tendrá compatibilidad hacia atrás para CPUs antiguas o diferentes. Si no necesita ejecutar código en otro sitio que en el sistema que está corriendo Gentoo, continúe con. Solo debería considerar usar  cuando necesite generar 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 tendrá en cuenta los conjuntos de instrucciones disponibles y ABI. No use  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  y los nombres de las opciones no es consistente entre arquitecturas, así que asegúrese de revisar el manual de   para determinar cual de ellas debería utilizar en su sistema.

-O
Lo siguiente es la variable. Controla el nivel de optimización de todo el código. Hace que la compilación de código tome algo más de tiempo, y puede usar mucha más memoria, especialmente al incrementar el nivel de optimización.

Existen siete ajustes para : ,  ,  ,  ,  ,   y. 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:


 * : Este nivel (la letra "O" seguida de un cero) desconecta por completo la optimización y es el predeterminado si no se especifica ningún nivel  en CFLAGS o CXXFLAGS. El código no se optimizará. Esto, normalmente, no es lo que se desea.


 * : Este es 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 bastante básico, pero conseguirá realizar correctamente el trabajo.


 * : Un paso delante de . Este es el nivel recomendado de optimización, a no ser que tenga necesidades especiales. -O2 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.


 * : Este es 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. Por ello no se recomienda usar -O3.


 * : Este nivel optimizará su código para reducir el tamaño. Activa todas las opciones de  que no aumenten el tamaño del código generado. Es útil para máquinas con capacidad limitada de disco o con CPUs con 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.

Como se comentó anteriormente,  es el nivel de optimización recomendado. Si un paquete muestra errores de compilación, asegúrese de que no está usando. Como otra opción pruebe configurando CFLAGS y CXXFLAGS a un nivel de optimización inferior, como -O1 o incluso -O0 -g2 -ggdb (para informar de errores y comprobar posibles problemas).

-pipe
Una opción común es. Realmente 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 este caso no use 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 añadiéndola a sus opciones. Aunque el manual de GNU  no especifica todas las arquitecturas en las que está activada al usar , hay que activarla explícitamente en un x86. Sin embargo, al usar esta opción la depuración se convierta en difícil o incluso 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. However, if you don't plan to do much software debugging and haven't added any other debugging-related CFLAGS such as, then you can try using.

-msse, -msse2, -msse3, -mmmx, -m3dnow
These flags enable the SSE, SSE2, SSE3, MMX, and 3DNow! instruction sets for x86 and x86-64 architectures. These are useful primarily in multimedia, gaming, and other floating point-intensive computing tasks, though they also contain several other mathematical enhancements. These instruction sets are found in more modern CPUs.

You normally don't need to add any of these flags to as long as you are using the correct   (for example,   implies  ). Some notable exceptions are newer VIA and AMD64 CPUs that support instructions not implied by  (such as SSE3). For CPUs like these you'll need to enable additional flags where appropriate after checking the output of.

But I get better performance with -funroll-loops -fomg-optimize!
No, you only think you do because someone has convinced you that more flags are better. Aggressive flags will only hurt your applications when used system-wide. Even the  manual says that using   and   makes code larger and run more slowly. Yet for some reason, these two flags, along with,  ,  , and similar flags, continue to be very popular among ricers who want the biggest bragging rights.

The truth of the matter is that they are dangerously aggressive flags. Take a good look around the Gentoo Forums and Bugzilla to see what those flags do: nothing good!

You don't 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 your code and get your bugs marked INVALID or WONTFIX.

You don't need dangerous flags like these. Don't use them. Stick to the basics:,  , and.

What about -O levels higher than 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.

Need more proof? Examine the  source code:

-O source code

As you can see, any value higher than 3 is treated as just.

¿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.

The Gentoo Developer Manual outlines where and how flag filtering/replacing works.

It's possible to circumvent  filtering by redundantly listing the flags for a certain level, such as , by doing things like:

Specifying redundant CFLAGS

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.

You will most likely continue to run into problems when you build a package with unacceptable flags. When you report your troubles on Bugzilla, the flags you use in will be readily visible and you will be told to recompile without those flags. Save yourself the trouble of recompiling by not using redundant flags in the first place! Don't just automatically assume that you know better than the developers.

¿Qué pasa con LDFLAGS?
Los desarrolladores de Gentoo ya han configurado LDFLAGS básicas y seguras en los perfiles base, de tal manera que no necesita cambiarlas.

¿Puedo usar opciones para cada paquete?
Puede encontrarse información acerca de como utilizar las variables de entorno por paquete (incluyendo CFLAGS) en el Manual de Gentoo, "Variables de entorno por paquete".

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




 * Wikipedia


 * Los Foros de Gentoo

Agradecimientos
Nos gustaría dar las gracias a los siguientes autores y editores por sus contribuciones a esta guía:


 * nightmorph