¿Es posible acelerar ./configure?

Para compilar un paquete de software en una estación de trabajo con muchos núcleos de CPU (digamos 12), la etapa de configuración a menudo toma mucho más tiempo que la etapa de compilación real porque ./configurerealiza las pruebas una por una, mientras se make -jejecuta gccy otros comandos en paralelo.

Siento que es una gran pérdida de recursos tener los 11 núcleos restantes inactivos la mayor parte del tiempo esperando ./configureque se complete la lentitud . ¿Por qué necesita hacer las pruebas secuencialmente? ¿Cada prueba depende la una de la otra? Puedo estar equivocado, pero parece que la mayoría de ellos son independientes.

Más importante aún, ¿hay alguna forma de acelerar ./configure?

Editar: para ilustrar la situación, aquí hay un ejemplo con GNU Coreutils

cd /dev/shm
rm -rf coreutils-8.9
tar -xzf coreutils-8.9.tar.gz
cd coreutils-8.9
time ./configure
time make -j24

Resultados:

# For `time ./configure`
real    4m39.662s
user    0m26.670s
sys     4m30.495s
# For `time make -j24`
real    0m42.085s
user    2m35.113s
sys     6m15.050s

Con coreutils-8.9 , ./configuretarda 6 veces más que make. Aunque ./configureusa menos tiempo de CPU (mira los tiempos de "usuario" y "sys"), lleva mucho más tiempo ("real") porque no está en paralelo. He repetido la prueba varias veces (con los archivos relevantes probablemente en la memoria caché) y los tiempos están dentro del 10%.

Recuerdo las discusiones en la lista de correo de Autoconf sobre este tema de hace aproximadamente 10 años, cuando la mayoría de las personas solo tenían un núcleo de CPU. Pero no se ha hecho nada, y sospecho que no se hará nada. Sería muy difícil configurar todas las dependencias para el procesamiento en paralelo configurey hacerlo de una manera que sea portátil y robusta.

Dependiendo de su escenario particular, puede haber algunas maneras de acelerar las ejecuciones de configuración de todos modos. Por ejemplo:

• Usa un caparazón más rápido. Por ejemplo, considere usar en dashlugar de bashas /bin/sh. (Nota: en Debian, dashestá parcheado para que configureno lo use, porque usarlo rompe muchos configurescripts).
• Si ejecuta compilaciones de forma remota (a través de ssh, por ejemplo), entonces he descubierto que la salida de la consola puede ser bastante lenta. Considera llamar configure -q.
• Si compila repetidamente el mismo proyecto, considere usar un archivo de caché. Llamar configure -C. Consulte la documentación de Autoconf para más detalles.
• Si crea muchos proyectos diferentes, considere usar un archivo de sitio ( config.site). Nuevamente, vea la documentación.
• Construye varios proyectos en paralelo.

Ha sido inteligente al usar ramdrive para que el árbol de origen resida, pero piénselo dos veces: ¿qué hace la configuración? Hace su trabajo verificando no solo su árbol fuente , sino también el sistema para la disponibilidad de bibliotecas, compiladores, etc. En este caso, el problema de acceso a veces reside en el acceso al disco. ejemplo, un sistema de archivos raíz basado en SSD.

Si está utilizando el gobernador de CPU a pedido, intente utilizar el de rendimiento. Esto ayuda en el i7 y a8-3850 en un 40-50%. No hace mucha diferencia en el q9300.

En una CPU de cuatro núcleos, podrías hacer

for cpu in `seq 0 3`; do sudo cpufreq-set -g performance -c $cpu; done

(La opción -r debería hacerlo para que no tenga que hacer cpufreq-set para cada núcleo, pero en mis computadoras no funciona).

Sin embargo, la opción de caché ayuda aún más.

Hay muchos tipos de ./configureguiones. Hay herramientas populares ( autconf es una de ellas) para ayudar a un desarrollador a crear un ./configurescript, pero no hay una regla que diga que cada desarrollador debe usar estas herramientas, y luego, incluso entre estas herramientas, puede haber grandes variaciones en la forma en que estos scripts son construidos

No conozco ningún ./configurescript popular que pueda ejecutarse en paralelo. La mayoría de los scripts creados por herramientas populares al menos almacenan en caché algunos o todos sus resultados, por lo que si lo ejecuta nuevamente (sin hacer un make cleanprimero, de todos modos), se ejecuta mucho más rápido la segunda vez.

Eso no quiere decir que no se pueda hacer ... pero sospecho que hay poca motivación para las personas que trabajan autoconf, por ejemplo, para hacerlo, ya que para la mayoría de los paquetes, la fase de configuración es muy rápida en relación con la compilación y el enlace reales fases

El disco duro es el cuello de botella en este caso. Para acelerar la compilación, compile en un sistema con unidades rápidas (léase: bajo tiempo de acceso). Hay mucho alboroto sobre los discos SSD, pero hubo algunas críticas con respecto a que no afectan el tiempo de compilación de manera positiva. Es decir, construir en SSD no fue mucho más rápido que en un disco sata decente. No recuerdo dónde leí esto porque el artículo tiene un par de años.

De todos modos ... Untar para embestir y construir desde allí.

mkdir /tmp/tmp 
mount -t tmpfs -o size=400M tmpfs /tmp/tmp 
cd /tmp/tmp
tar xjf somesourcetarball-1.1.33.tar.bz2

Su pregunta podría ser incluso más relevante hoy, ya que tenemos CPU de doce núcleos con un rendimiento de núcleo único (bastante) bajo. Las compilaciones automatizadas para la integración continua (CI) realmente desperdician mucho tiempo / energía de CPU para cada confirmación. Lo mismo con saltar entre las ramas.

Así que revisa / lee mis consejos sobre cómo acelerar el proceso en https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain .

"¿Por qué necesita hacer las pruebas secuencialmente? ..." De hecho, hay algunas cosas que se pueden hacer en paralelo, mientras que otras tienen que ser secuenciales. Varias cosas dependen del entorno de compilación, y el script de configuración en sí mismo es independiente del sistema. Ni siquiera contiene bashismos, por lo que funciona con un shell POSIX puro.

Si desea escribir software portátil, no hay otro sistema de compilación como autotools. Pero si no le importa la portabilidad (amplia), evite las herramientas automáticas: hay una gran cantidad de herramientas de compilación rápidas y suficientemente buenas.