¿Es posible acelerar ./configure?

29

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

— netvope
fuente

44

Es ridículo y una pena que NO haya buenas herramientas de construcción. Todos los que existen están allí puramente por inercia. Construir binarios es una cosa tan complicada e impredecible.

— Matt Joiner

Hace las pruebas secuencialmente porque sería una pesadilla descubrir cómo hacer paralelismo en el sistema particular en el que se está ejecutando.

— Simon Richter

13

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.

— Peter Eisentraut
fuente

2

Podría explicar un poco más por qué makese puede paralelizar pero configureo autoconfno se puede?

— netvope

Parece que tengo algunos problemas de rendimiento con el shell. Ejecutar sh -c "echo $i" > /dev/null1000 veces toma alrededor de 10 segundos en este sistema, pero solo 1-2 segundos en mis otros sistemas.

— netvope

1

GNU make utiliza un código C bastante complicado para iniciar y administrar múltiples procesos. los scripts de configuración se escriben en shell Bourne portátil. Sería posible, pero probablemente muy difícil.

— Peter Eisentraut

44

Ordenar las dependencias entre las configurepruebas es en realidad una operación de baja complejidad (clasificación topológica) y se ha resuelto en los primeros días de la informática. El verdadero problema es que nadie se molestó en agregar el código a la configuración automática para hacerlo y el hecho de que muchos programadores modifican manualmente los archivos generados. Todo el sistema debe renovarse para que la configuración ya no se realice mediante un script de shell, sino un archivo de metadatos de lectura binaria residente.

— billc.cn

1

Agregue una referencia a la discusión mencionada en la lista de correo (un enlace al archivo).

— Karl Richter

3

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.

— bubu
fuente

1

Desafortunadamente, parece que los SSD no ayudarán mucho. Intenté correr ./configurerepetidamente pero las ejecuciones posteriores tardan casi tanto como la primera. Como hay mucha memoria libre en el sistema, creo que el sistema ejecuta los compiladores y las bibliotecas desde la memoria caché sin ir al disco.

— netvope

1

si intentó ejecutar ./configure repetidamente (y si se realiza mediante autoconf), debería tener todos los resultados almacenados en caché y debería funcionar muy bien. Puede publicar el script de configuración para que lo veamos si desea más ayuda. Estoy bastante seguro de que hay una gran cantidad de guru aquí

— bubu

De hecho, lo limpié entre ejecuciones ( ./configuresiempre se ejecuta en un árbol fuente recién extraído). Voy a agregar más detalles en la publicación original (el espacio es limitado aquí).

— netvope

Acabo de probar sin limpiar la carpeta (es decir, se ejecuta ./configureinmediatamente después de otra ./configure) y las dos ejecuciones toman aproximadamente la misma cantidad de tiempo. ¿Significa que el almacenamiento en caché no funciona probablemente en mi sistema?

— netvope

Buscaré coreutils e intentaré configurar cuando tenga tiempo. Manténganse al tanto.

— bubu

3

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.

— Dan Kegel
fuente

3

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

— Flimzy
fuente

2

Sin embargo, hay una buena razón para usar estas herramientas: son maduras y realizan un seguimiento de muchos de los pequeños detalles. Creo que Linux no estaría en una posición tan excelente en el mundo incrustado si no pudiera simplemente apuntar el script de configuración a su compilador cruzado y hacer que funcione el 90% del tiempo.

— Simon Richter

2

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

— Ярослав Рахматуллин
fuente

1

Gracias, pero yo ya estaba compilando en / dev / shm que es un tmpfs :-)

— netvope

0

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.

— Tim Ruehsen Rockdaboot
fuente