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. CFLAGS are for code written in C, while CXXFLAGS are 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 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.

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 opciones 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 principal por la que existen las opciones 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 las opciones agresivas pueden arruinar el código.)

Conceptos básicos
The goal behind using 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 we'll stick with combinations known to work well. Ideally, they are the best available for any CPU architecture. We'll mention the aggressive flags later so you know what to look out for. We won't discuss every option listed on the gcc manual (there are hundreds), but we'll cover the basic, most common flags.

-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:

To get more details, including  and   values, use:

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

Also available are the  and   flags. These flags are normally only used when there is no available  option; certain processor architectures may require   or even. Unfortunately, gcc 's behavior isn't very consistent with how each flag behaves from one architecture to the next.

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.

Only non-x86/x86-64 CPUs (such as Sparc, Alpha, and PowerPC) may require  or   instead of. On these architectures,  /   will sometimes behave just like   (on x86/x86-64)... but with a different flag name. Again, gcc 's behavior and flag naming just isn't consistent across architectures, so be sure to check the gcc manual to determine which one you should use for your system.

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


 * : 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  o incluso   (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
This is a very common flag designed to reduce generated code size. It is turned on at all levels of  (except  ) on architectures where doing so does not interfere with debugging (such as x86-64), but you may need to activate it yourself by adding it to your flags. Though the gcc manual does not specify all architectures it is turned on by using, you will need to explicitly activate it on x86, with gcc up to version 4.6 or when using. However, using this flag will make debugging hard to impossible.

En particular, provoca que la localización de problemas en aplicaciones escritas en Java sea mucho más complicada, aunque Java no es el único código afectado al usar esta opción. Así, aunque esta opción puede ayudar, la depuración será complicada. En particular, las trazas de ejecución (backtraces) no servirán de mucho. Sin embargo, si no planea hacer muchas depuraciones y no tiene añadida ninguna otra CFLAG relacionada con la depuración como  (y no está instalando paquetes con la variable USE  ), entonces intente usar.

-msse, -msse2, -msse3, -mmmx, -m3dnow
Estas opciones activan los conjuntos de instrucciones 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 necesita añadir ninguna de estas opciones a mientras esté usando 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 necesitará habilitar opciones adicionales donde sea apropiado después de verificar la salida de.

Sin embargo, ¡Consigo mejor rendimiento con -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 gcc 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.

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!

No necesita usar estas opciones globalmente en CFLAGS o en CXXFLAGS. Solo dañarán el rendimiento. Puede sonarle como que tiene un sistema avanzado de alto rendimiento, pero no hará más que inflar su código y marcar sus informes de error como INVALID o 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
Algunos usuarios alardean de que obtienen mejor rendimiento usando,   y similares, pero la realidad es que niveles de   mayores que 3 no tienen efecto. El compilador puede aceptar CFLAGS como, pero realmente no hace nada con él. Solo realiza la optimización para, nada más.

Need more proof? Examine the source code:

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?
A menudo CFLAGS y CXXFLAGS que se han activado en varios niveles de  están especificadas de forma redundante en. A veces esto ocurre por ignorancia, pero también se hace para permitir el filtrado o el reemplazo de opciones.

El filtrado y el reemplazo de opciones se realiza en muchos ebuilds del árbol Portage. Normalmente se realiza debido a que algunos paquetes no compilan con determinados niveles  o cuando el código fuente es tan sensible que no se pueden utilizar opciones adicionales. El ebuild bien filtrará algunas opciones o todas las opciones CFLAGS y CXXFLAGS, bien reemplazará  con un nivel diferente.

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:

Sin embargo, hacer esto no es algo acertado. ¡Las CFLAGS se filtran por alguna razón! Cuando estas opciones se filtran es porque es inseguro construir paquetes con ellos. Claramente, no es seguro compilar su sistema completo con  si alguna de estas opciones está activada para este nivel causará problemas con ciertos paquetes. Por lo tanto, no debería intentar "saber más" que los desarrolladores que mantienen estos paquetes. Confíe en ellos. ¡El filtrado y reemplazo de opciones se hace por su bien!. Si un ebuild especifica opciones alternativas, entonces no intente evitarlas.

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?
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


 * man make.conf


 * Wikipedia


 * Los Foros de Gentoo