Optimizacion de MAKEOPTS en Gentoo

Traducción del articulo MAKEOPTS="-j${core} + 1" is NOT the best optimization publicado por Agostino Sarubbo (ago), que forma parte del Proyecto Gentoo/AMD64, participando tanto en su desarrollo como en la estabilización.

MAKEOPTS="-j${core} + 1" NO es la mejor optimización
Muchas veces, al ajustar el make.conf en sistemas con una arquitectura concreta, he dudado con que valor es el mejor para la opción -jobs. El manual de Gentoo sugiere usar ${core} + 1, pero por curiosidad quise comprobarlo por mi mismo para asegurarme de que es lo adecuado.

Para realizar correctamente la prueba necesitamos un paquete con un sistema de construcción consistente que respete la paralelización y tarde por lo menos unos minutos en compilarse. De otra forma, con paquetes que se compilen en unos segundos no podremos notar realmente la diferencia. kde-base/kdelibs es, en mi opinión, perfecto.

Si usas una arquitectura en la que no este disponible kde-base/kdelibs, simplemente reemplazalo por otro paquete basado en cmake.

Ahora, descarga best_makeopts de mi overlay. A continuación varias recomendaciones y una explicación de que hace el script.

  • Necesitas compilar el paquete en un sistema de archivos tmpfs, y estoy asumiendo que también tienes montado /tmp con un sistema de archivos tmpfs.
  • Necesitas que el tarball del paquete este en un sistema de archivos tmpfs ya que si tienes un disco duro lento, puede influir aumentando los tiempos de compilación.
  • Necesitas cambiar el governor usado por tu CPU para que use performance.
  • Necesitas asegurarte de que no has añadido opciones extrañas a la variable EMERGE_DEFAULT_OPTS.
  • Necesitas añadir la opción -B a emerge ya que no queremos incluir los tiempos de instalación.
  • Necesitas eliminar la cache existente antes de comenzar a compilar.

Como puedes ver, el bucle for realizara un emerge del mismo paquete asignando a MAKEOPTS valores desde 1 hasta 10. Si tienes, por ejemplo, una maquina con un único núcleo, sera suficiente con realizar el bucle for desde 1 hasta 4.
#!/bin/bash

cpufreq-set -g performance -r

PACKAGE="kde-base/kdelibs"

DISTDIR="/tmp/" emerge -f ${PACKAGE}

for i in {1..10}
do
 echo 1 > /proc/sys/vm/drop_caches
 time DISTDIR="/tmp" EMERGE_DEFAULT_OPTS="" MAKEOPTS="-j${i}" emerge -q1OB ${PACKAGE}
 echo -ne "\n\n\n"
done
Por favor, durante la prueba, no uses la CPU para otros propósitos, y si puedes, para todos los servicios y realiza la prueba desde la tty. Se mostraran los tiempos para cada emerge.

El siguiente es un ejemplo utilizando mi maquina:
-j1 : real 29m56.527s
-j2 : real 15m24.287s
-j3 : real 13m57.370s
-j4 : real 12m48.465s
-j5 : real 12m55.894s
-j6 : real 13m5.421s
-j7 : real 13m13.322s
-j8 : real 13m23.414s
-j9 : real 13m26.657s
El hardware utilizado es el siguiente: Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz, el cual tiene 2 CPUs y 4 threads. Puedes ver como tras asignar el valor -j4 se produce una regresión.

Otro ejemplo utilizando un Intel(R) Itanium(TM) con 4 CPUs:
-j1 : real 4m24.930s
-j2 : real 2m27.854s
-j3 : real 1m47.462s
-j4 : real 1m28.082s
-j5 : real 1m29.497s
He probado el script en ~20 maquinas diferentes y en la mayoría de los casos, la mejor optimización fue ${core} o mas exactamente ${threads} de la CPU.

Conclusiones obtenidas de la prueba
No se quien, hace años, sugirió en el manual de Gentoo ${core} + 1 no pretendo iniciar un flame. Tan solo estoy diciendo que, ${core} + 1 no es la mejor optimización para mi y las pruebas confirman la parte del manual: "[...] aunque este valor no es siempre el perfecto.".
El valor sugerido se obtiene sumando uno a la cantidad de CPUs (o de cores) de su sistema, aunque este valor no es siempre el perfecto.
En todos los casos ${threads} + ${X} es mas lento que solo ${threads}, así que no uses -j20 si tienes una CPU con 2 núcleos.

Además, no estoy diciendo que uses ${threads}, tan solo estoy diciendo que no dudes en realizar tus propias pruebas para ver cual es la mejor optimización.

Si tienes sugerencias para mejorar el funcionamiento del script o crees que el script esta mal, no dudes en comentarlo o enviar un email.