Optimización de GCC

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.

Default CFLAGS can be set in make.conf for Gentoo systems. CFLAGS can also be specified per-package.

See also
For more information see CFLAGS and CXXFLAGS in the Gentoo Handbook, and the safe CFLAGS article. See also the FAQ.

Introducción

¿Qué son CFLAGS y CXXFLAGS?

Las variables de entornoCFLAGS y CXXFLAGS son las que se utilizan convencionalmente para especificar opciones de compilación en un sistema de construcción cuando se compila código C y C++. Aunque estas variables no están estandarizadas, su utilización es esencialemente ubicua y cualquier construcción escrita correctamente debería interpretarlas de forma adecuada para el paso de opciones extra o personalizadas cuando se invoca el compilador. Leer la página info de GNU make para obtener una lista de las variables más comúnmente utilizadas en esta categoría.

Debido a que gran parte de los paquetes que se utilizan en los sistemas Gentoo están escritos en C y C++, existen dos variables que los administradores definitivamente querrán configurar adecuandamente ya que tienen gran influencia en la forma en que se construye el sistema.

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 manual de GCC ofrece una lista completa opciones disponibles y sus aplicaciones.

¿Cómo se utilizan?

Normalmente, se deberían definir CFLAGS y CXXFLAGS en el entorno cuando se invoque un guión o en los ficheros makefile generados por el programa automake. En los sistemas basados en Gentoo, se la variables CFLAGS y CXXFLAGS se definen en /etc/portage/make.conf. Las variables definidas en este fichero se exportarán al entorno de los programas invocados por portage de modo que todos los paquetes se compilarán usando estas opciones como base.

CÓDIGO Ajustar CFLAGS en /etc/portage/make.conf

CFLAGS="-march=skylake -O2 -pipe"
CXXFLAGS="${CFLAGS}"

Importante
Aunque es posible tener varias líneas en los ajustes USE, hacer lo mismo en CFLAGS puede y dará problemas con programas como cmake. Asegúrese de que la declaración de CFLAGS se realiza en una sola línea con el menor número posible de espacios en blanco para evitar estos problemas. Eche un vistazo a la incidencia bug #500034 a modo de ejemplo.

Como se puede observar en el ejemplo de arriba, CXXFLAGS se define para usar todas las opciones presentes en CFLAGS. Prácticamente la mayoría de los sistemas se configurarán de este modo. Las opciones adicionales de CXXFLAGS son menos comunes y normalmente no se aplican de modo tan general como para ser definidas globalmente.

Consejo
El artículo Ajustes CFLAGS seguros puede ser de ayuda para principiantes que comience a optimizar sus sistemas.

Confusiones

Aunque el hecho de activar algunas optimizaciones de la compilación en CFLAGS puede ser muy efectivo a la hora de producir binarios pequeños o más rápidos, pueden también deteriorar la función del código, inflar su tamaño, ralentizar su tiempo de ejecución o simplemente causar un fallo en la construcción. El momento en el que se empieza a notar la bajada en el rendimiento se alcanza más rápidamente cuando se modifica CFLAGS. No ajuste estas opciones de forma arbitraria.

Recuerde, la variable global CFLAGS configurada en /etc/portage/make.conf se aplicará a todo paquete del sistema de modo que los administradores normalmente definirán opciones generales de amplia aplicación. Los paquetes individuales modificarán a continuación estas opciones bien en su ebuild o en el propio ebuild del sistema para generar el conjunto de ajustes que se utilizarán cuando se lance el compilador.

¿Preparado?

Conociendo los riesgos involucrados, echemos un vistazo a algunas optimizaciones sanas y seguras para su computadora. Esto le será útil y también alentador para los desarrolladores la próxima vez que se informe de un problema en Bugzilla. (Los desarrolladores suelen pedir al usuario que recompile un paquete con los CFLAGS mínimos para ver si el problema persiste. Recuerde: ¡Las opciones agresivas pueden arruinar el código!)

Optimización

Conceptos básicos

El objetivo de usar CFLAGS y CXXFLAGS es crear código específico para el sistema; debería funcionar perfectamente y ser ligero y rápido, si es posible. Algunas veces estás condiciones son mutuamente excluyentes, de modo que esta guía trabaja con combinaciones que se sabe que funcionan bien. Idealmente, las mejores están disponibles para cada arquitectura de CPU. Se cubren más adelante, a modo de información, ajustes más agresivos. No se discuten todas las opciones listadas en el manual de GCC, sin embargo se revisarán las opciones más comunes.

Nota
Cuando no esté seguro de la función que realiza determinada opción, acuda al capítulo correspondiente del de opciones Options de GCC. Si aún continúa atascado después de mirar en el manual, pruebe con un motor de búsquega o revise las listas de correo de GCC

-march

La primera y más importante opción es -march. 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 -march 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 teniendo en cuenta que el código fuente está preparado para usarlos. Por ejemplo, para poder utilizar instrucciones AVX, se debe adaptar el código fuente para ofrecer soporte.

-march= es una opción ISA seleccionable que le indica al compilador que puede utilizar las instrucciones del conjunto de instrucciones de esa arquitectura. En una plataforma Intel/AMD64 con -march=native -O2 o un nivel OPT inferior, el código terminará conteniendo instrucciones AVX pero usará registros SSE XMM más cortos. Para tener la ventaja completa de los registros AVX YMM se deben utilizar las opciones -ftree-vectorize, -O3 o -Ofast así como.

La opción -ftree-vectorize es una opción de optimización (por defecto en -O3 y -Ofast), que intenta vectorizar los bucles utilizando la ISA seleccionada si es posible. La razón de que no esté activa en -O2 es que no siempre mejora el código, también puede hacer que el código sea más lento y normalmente hace que el código sea más largo, que dependa realmente del bucle, etc.

A pesar que la variable CHOST en /etc/portage/make.conf especifica la arquitectura general utilizada, -march 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 -march.

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

user $cat /proc/cpuinfo

o incluso instalar app-portage/cpuid2cpuflags y añadir las opciones específicas para cada CPU disponibles al fichero /etc/portage/package.use/00cpuflag, que la herramienta recorre, por ejemplo la variable CPU_FLAGS_X86:

user $cpuid2cpuflags

CPU_FLAGS_X86: aes avx avx2 f16c fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3

root #echo "*/* $(cpuid2cpuflags)" >> /etc/portage/package.use/00cpuflags

Para obtener más detalles, incluyendo valores march y mtune se pueden utilizar dos órdenes.

• La primera orden le indica al compilador que no realice ningún enlazado (-c) y en lugar de interpretar la opción --help para clarificar las opciones de la línea órdenes, ahora muestra si ciertas opciones están habilitadas o deshabilitadas (-Q). En este caso, las opciones mostradas son las que se han habilitado para el objetivo seleccionado:
  user $gcc -c -Q -march=native --help=target

• La segunda orden muestra las directivas de compilación para construir el fichero cabecera pero sin realmente realizar los pasos y en su lugar mostrarlos en pantalla (-###). La línea de salida final es la orden que mantiene todas las opciones de optimización y selección de arquitectura:
  user $gcc -### -march=native /usr/include/stdlib.h

Nota
The l2-cache-size option represents processor's last level cache (L2 or higher if present).

• The glibc-hwcaps feature (>=sys-libs/glibc-2.33) can be used to define -march for a more general processor architecture (for >=sys-devel/gcc-11):

user $/lib64/ld-linux-x86-64.so.2 --help

...
Subdirectories of glibc-hwcaps directories, in priority order:
 x86-64-v4
 x86-64-v3 (supported, searched)
 x86-64-v2 (supported, searched)
 x86_64 (supported, searched)

In this example, the cpu supports x86-64-v3 psABI x86_64 which can be used for -march=x86-64-v3.

Ahora veamos a -march en acción. Este ejemplo es para un antiguo chip AMD Athlon 64:

CÓDIGO Ejemplo para AMD64

CFLAGS="-march=athlon64"
CXXFLAGS="${CFLAGS}"

Aquí hay otro para un procesador Intel común:

ARCHIVO /etc/portage/make.confEjemplo para Intel Core

CFLAGS="-march=skylake"
CXXFLAGS="${CFLAGS}"

Si no se puede determinar el tipo de CPU o si e usuario no sabe que ajustes elegir, es posible utilizar el ajuste -march=native. 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 -march=native. La palabra "native" significa que el código producido podrá ejecutarse solamente en ese tipo de CPU. Las aplicaciones construidas con -march=native en una CPU Intel Core no podrán ejecutarse en una CPU Intel Atom más antigua.

También están disponibles las opciones -mcpu y -mtune. Cada una de ellas solo se usará cuando no haya otra opción -march disponible. Ciertas arquitecturas de procesador pueden requerir -mtune o incluso de -mcpu. 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, -mcpu 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 -mtune cuando se genere código para CPUs antiguas como i386 e i486. -mtune produce un código más genérico que -march; 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 -mcpu en sistemas x86 o x86-64, ya que es obsoleto para estas arquitecturas.

Solo las CPUs que no sean x86/x86-64 (como ARM, SPARC, Alpha y PowerPC) pueden requerir -mtune o -mcpu en lugar de -march. En estas arquitecturas, -mtune/-mcpu algunas veces se comportará como -march 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.

Nota
Para más sugerencias de configuraciones de -march/-mtune/-mcpu, por favor lea el capítulo 5 del manual de instalación de Gentoo para la arquitectura. También, lea el manual de GCC listado en la página de opciones específicas por arquitectura con explicaciones más detalladas sobre las diferencias entre -march, -mcpu, y -mtune.

Advertencia
No utilice -march=native o -mtune=native en las variables CFLAGS o CXXFLAGS de make.conf cuando compile con distcc.

-O

Advertencia
Usar -O3 o -Ofast puede causar que algunos paquetes se rompan durante la compilación.

Nota
Para imprimir todos los paquetes que fueron construidos con un CFLAGS/CXXFLAGS específico es posible usar el siguiente comando: grep Ofast /var/db/pkg/*/*/CFLAGS

Hablaremos ahora de la variable -O. 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 -O: -O0, -O1, -O2, -O3, -Os, -Og y -Ofast. Se debe utilizar solo uno de ellos en /etc/portage/make.conf.

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

Examinemos cada nivel de optimización:

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

• -O1: 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.

• -O2: Un paso delante de -O1. Es el nivel recomendado de optimización, a no ser que el sistema tenga necesidades especiales. -O2 activará algunas opciones añadidas a las que se activan con -O1. Con -O2, el compilador intentará aumentar el rendimiento del código sin comprometer el tamaño y sin tomar mucho más tiempo de compilación. Se puede utilizar SSE o AVX en este nivel pero no se utilizarán registros YMM a menos que también se habilite ftree-vectorize.

• -O3: El nivel más alto de optimización posible. Activa optimizaciones que son caras en términos de tiempo de compilación y uso de memoria. El hecho de compilar con -O3 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 -O3 puede romper algunos paquetes. No se recomienda utilizar -O3. Sin embargo, también habilita -ftree-vectorize de modo que los bucles dentro del código se vectorizarán y se utilizarán los registros AVX YMM.

• -Ofast: Nuevo en GCC 4.7. Consiste en el ajuste -O3 más las opciones -ffast-math, -fno-protect-parens y -fstack-arrays. Esta opción rompe el cumplimiento de estándares estrictos y no se recomienda su utilización.

• -Os: Optimizará el tamaño del código. Activa todas las opciones de -O2 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é.

• -Oz: Introduced in GCC 12.1, more aggressively optimize for size than -Os. Note this will heavily degrade runtime performance than -O2, due to increasing the number of instructions executed if those instructions require fewer bytes to encode.

• -Og: En GCC 4.8 aparece un nuevo nivel del optimización general: -Og. 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 -O0. Observe que -Og no implica -g, éste simplemente deshabilita optimizaciones que podrían interferir con la depuración.

Como se comentó anteriormente, -O2 es el nivel de optimización recomendado. Si un paquete muestra errores de compilación, se debe comprobar que no se está usando -O3. Como otra opción se puede probar a configurar 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 -pipe. 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 -O (excepto -O0) 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 -O. Todavía es necesario habilitar explícitamente la opción -fomit-frame-pointer. Para activarla en una arquitectura x86-32 con GCC hasta la versión 4.6 o cuando se utilice -Os en x86-32 con cualquier versión de GCC. Sin embargo, al usar -fomit-frame-pointer la depuración será algo difícil o incluso resultará imposible.

En particular, provoca que la localización de problemas en aplicaciones escritas en Java y compiladas con gcj 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. Cuando no se haga depuración de software y no se ha añadido ninguna otro ajuste CFLAGS relacionado con la depuración como -ggdb entonces intente usar -fomit-frame-pointer.

Importante
No combine -fomit-frame-pointer con la opción de nombre similar -momit- leaf-frame-pointer. No se aconseja la utilización de esta última, ya que -fomit-frame-pointer ya hace el trabajo apropiado. Es más, -momit-leaf-frame-pointer ha demostrado que impacta negativamente en el rendimiento del código.

-msse, -msse2, -msse3, -mmmx, -m3dnow

Estas opciones activan los conjuntos de instrucciones SSE, SSE2, SSE3, MMX y 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.

Importante
Asegúrese de comprobar si la CPU ofrece soporte para estos conjuntos de instrucciones lanzando la orden cat/proc/cpuinfo. La salida incluirá cualquier conjunto de instrucciones adicionales. Observe que pni es solo otro nombre para SSE3.

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

Nota
Revisar la lista de opciones específicas para x86 y x86-64 para ver cuales de estos conjuntos de instrucciones los activa la propia configuración del tipo de CPU. Si aparece una instrucción, entonces no se necesita especificar de forma independiente, se activará al usar la configuración de -march apropiada.

Hardening optimizations

Nota
While it is possible to use a hardened profile, it certainly isn't necessary for adding some hardening flags to /etc/portage/make.conf on a different profile. Especially on a desktop system, the use of position independent code (PIC) and position independent executables (PIE) on a system-wide level may cause compilation failures.

Hardening an otherwise unhardened system, like when using a desktop profile, can be considered a GCC optimization as well, especially in the light of security vulnerabilities such as Meltdown and Spectre.

Some packages feature an individual hardened USE flag, enabling tested security enhancements (like CFLAGS/CXXFLAGS). It may be a good idea to set this system-wide in /etc/portage/make.conf.

Nota
Reading section Do I need to pass any flags to LDFLAGS/CFLAGS in order to turn on hardened building? in the Hardened/FAQ is recommended for retrieving some basic hardened CFLAGS/CXXFLAGS.

Advertencia
Changing the CFLAGS/CXXFLAGS can cause problems and in some cases may even render a system unusable. Rebuilding the whole system with emerge -e @world may resolve the situation.

Overflow protection

Optimizing CFLAGS/CXXFLAGS for overflow protection can be a good idea if security concerns outweigh speed optimization. This may be the case on a daily-use desktop system, while e.g. on an optimized gaming PC it will be considered counterproductive.

For GCC version 12, package sys-devel/gcc, the USE flags default-stack-clash-protection and default-znow will automatically enable additional overflow protection.

Nota
A lot of these flags are now applied internally through the GCC toolchain automatically under the hardened profile, and some even under the regular profile. See table at Hardened/Toolchain.

CFLAGS/CXXFLAGS	LDFLAGS	function
-D_FORTIFY_SOURCE=2		run-time buffer overflow detection
-D_GLIBCXX_ASSERTIONS		run-time bounds checking for C++ strings and containers
-fstack-protector-strong		stack smashing protector
-fstack-clash-protection		increased reliability of stack overflow detection
-fcf-protection		control flow integrity protection
	-Wl,-z,defs	detect and reject underlinking
	-Wl,-z,now	disable lazy binding
	-Wl,-z,relro	read-only segments after relocation

ASLR

Address Space Layout Randomization (ASLR) is measure to increase security by randomly placing each function and buffer in memory. This makes it harder for attack vectors to succeed.

PIE is enabled by default when it is safe to do so on all 17.0 profiles. PIC may also be enabled by default on executables for architectures that require it (like AMD64).

There is no need to set PIE or PIC manually in CFLAGS.

CFLAGS/CXXFLAGS	LDFLAGS	function
-fpie	-Wl,-pie	full ASLR for executables
-fpic -shared		no text relocations for shared libraries

Preguntas frecuentes sobre optimización

Higher version of GCC should mean better optimizations?

Not always because of software regression, where an optimization with an earlier version of GCC no longer optimizes. A full list of regressions can be found at this link. Should this happen, please file a bug to Gentoo's bugzilla and/or GCC's bugzilla.

Is there a perfect optimizer?

No, because it would solve the halting problem, where it can tell if any program stops or runs forever .

What about optimizing GCC itself?

gcc has pgo and lto use flags that enables Profile Guided Optimization and Link Time Optimization respectively. To enable for building gcc itself with PGO and LTO:

ARCHIVO /etc/portage/package.use/gcc

sys-devel/gcc pgo lto

In Gentoo, a 3-stage bootstrap of gcc is done, meaning it compiles itself three times . In stage1, gcc is complied using an older gcc. In stage2, gcc is compiled using stage1 gcc. In stage3, gcc is compiled using stage2 gcc and is used to verify that stage2 gcc and stage3 gcc are the same. This is done because it is tested more completely and has better performance. The lto use flag adds -flto to BOOT_CFLAGS. The pgo use flag adds -fprofile-generate to stage2 gcc and adds -fprofile-use -fprofile-reproducible=parallel-runs to stage4 gcc.

gcc performance may improve via PGO, although it may as much as double the compile times.

Sin embargo, ¡Consigo mejor rendimiento con -funroll-loops -fomg-optimize!

No, la gente piensa que lo hacen porque alguien les ha convencido de 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 -funroll-loops y -funroll-all-loops 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 -ffast-math, -fforce-mem, -fforce-addr, 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!

Estos ajustes no son necesarios globalmente en CFLAGS o en CXXFLAGS. Solo dañarán el rendimiento. Podría incluso dar pie a pensar de que se está corriendo un sistema de alto rendimiento con el software más actual, pero no hará más que inflar el código y marcar sus informes de error como INVALID o WONTFIX.

No se necesitan opciones peligrosas como estas. No las utilice. Quédese con las básicas: -march, -O y -pipe.

¿Qué pasa con los niveles -O mayores que 3

Algunos usuarios alardean de que obtienen mejor rendimiento usando -O4, -O9 y similares, pero la realidad es que niveles de -O mayores que 3 no tienen efecto. El compilador puede aceptar CFLAGS como -O4, pero realmente no hace nada con él. Solo realiza la optimización para -O3, nada más.

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

CÓDIGO Código fuente -O

case OPT_LEVELS_3_PLUS:
      enabled = (level >= 3);
      break;
 
 case OPT_LEVELS_3_PLUS_AND_SIZE:
      enabled = (level >= 3 || size);
      break;

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

¿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 -march=native) 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 -march como native). 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 -march 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 -O están especificadas de forma redundante en /etc/portage/make.conf. 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 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á -O 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 -O filtrando mediante el listado redundante de opciones para un cierto nivel, como -O3, haciendo cosas como:

CÓDIGO Especificar CFLAGS redundantes

CFLAGS="-O3 -finline-functions -funswitch-loops"

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 el sistema completo con -O3 si alguna de estas opciones está activada para este nivel causará problemas con ciertos paquetes. Por lo tanto, no intente "saber más" que los desarrolladores que mantienen estos paquetes. Confíe en ellos. ¡El filtrado y reemplazo se realiza para garantizar la estabilidad del sistema y de las aplicaciones!. Si un ebuild especifica opciones alternativas, entonces no intente evitarlas.

Si se construyen paquetes con ajustes inaceptables lo más probable es que aparezcan los problemas. Cuando se informe de problemas en Bugzilla, los ajustes que se utilizan en /etc/portage/make.conf serán visibles rápidamente y los desarrolladores pedirán la recompilación sin esos ajustes. ¡Evite el engorro que supone recompilar no utilizando ajustes 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 se necesita cambiarlas.

¿Puedo usar opciones para cada paquete?

Advertencia
El uso de opciones específicas de paquetes complica la depuración y el soporte. Asegúrese de mencionarlo en los informes de fallos junto a los cambios que haya realizado.

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

Profile Guided Optimization (PGO)

Not to be confused with the packages.gentoo.org tool and website.

Profile guided optimization (PGO) consists of compiling and profiling a program to assess hot paths in the code. Optimizations are then applied based on this analysis. Specifically, the code is compiled with -fprofile-generate, which instrument the code. Second, the code is run with applications to collect profile information. Finally, using the profiled data, the code is compiled with -fprofile-use. To manually enable PGO for packages, see this link.

Firefox also supports PGO although sometimes it may break the build.

Link Time Optimization (LTO)

Nota
LTO heavily increases compile times and if changing even one object file when compiling, LTO recompiles the whole code again. There is a ongoing GSoC project to make sure LTO only recompiles what it deems necessary.

LTO is still experimental. LTO may need to be disabled before reporting bugs because it is a common source of problems. The -flto flag is used, with an optional auto argument (Detects how many jobs to use) or a integer argument (An integer number of jobs to execute parallel).

See the LTO article for more information on LTO on Gentoo.

Véase también

Configurar las opciones de compilación (Manual de AMD64)

Recursos Externos

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

• La documentación en línea de GCC

Referencias

---

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document:
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.