Est-il possible d'accélérer ./configure?

Pour compiler un progiciel sur un poste de travail avec de nombreux cœurs de processeur (disons 12), l'étape de configuration prend souvent beaucoup plus de temps que l'étape de compilation proprement dite car elle ./configureeffectue les tests un par un, tout en make -js'exécutant gccainsi que d'autres commandes en parallèle.

Je pense que c'est un énorme gaspillage de ressources que de laisser les 11 cœurs restants inactifs la plupart du temps en attendant la fin du ralentissement ./configure. Pourquoi doit-il effectuer les tests de manière séquentielle? Chaque test dépend-il les uns des autres? Je peux me tromper, mais il semble que la majorité d'entre eux soient indépendants.

Plus important encore, existe-t-il des moyens d'accélérer ./configure?

Edit: Pour illustrer la situation, voici un exemple avec 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

Résultats:

# 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

Avec coreutils-8.9 , ./configureprend 6 fois plus longtemps que make. Bien que vous ./configureutilisiez moins de temps CPU (regardez les temps "utilisateur" et "sys"), cela prend beaucoup plus de temps ("réel") car il n'est pas parallélisé. J'ai répété le test plusieurs fois (avec les fichiers pertinents restant probablement dans le cache mémoire) et les délais sont à moins de 10%.

Je me souviens des discussions sur la liste de diffusion Autoconf à propos de ce problème il y a environ 10 ans, alors que la plupart des gens n'avaient en fait qu'un seul cœur de processeur. Mais rien n'a été fait, et je soupçonne que rien ne sera fait. Il serait très difficile de configurer toutes les dépendances pour le traitement parallèle configureet de le faire de manière portable et robuste.

Selon votre scénario particulier, il existe de toute façon plusieurs façons d'accélérer les exécutions de configuration. Par exemple:

• Utilisez un shell plus rapide. Par exemple, envisagez d'utiliser dashau lieu de bashas /bin/sh. (Remarque: sous Debian, il dashest corrigé de sorte qu'il configurene l'utilise pas, car son utilisation rompt beaucoup de configurescripts.)
• Si vous exécutez des builds à distance (via ssh, par exemple), j'ai constaté que la sortie de la console peut être assez lente. Pensez à appeler configure -q.
• Si vous générez plusieurs fois le même projet, envisagez d'utiliser un fichier cache. Appelle configure -C. Voir la documentation Autoconf pour plus de détails.
• Si vous créez de nombreux projets différents, envisagez d'utiliser un fichier de site ( config.site). Encore une fois, consultez la documentation.
• Construisez plusieurs projets en parallèle.

Vous avez été intelligent en utilisant ramdrive pour que le sourcetree réside, mais réfléchissez-y à deux fois - que fait la configuration? Il fait son travail en vérifiant non seulement votre sourcetree , mais aussi souvent le système pour les disponibilités de la bibliothèque, des compilateurs, etc. Dans ce cas, le problème d'accès réside parfois dans l'accès au disque - Vous le ferez beaucoup plus rapidement si vous avez pour par exemple un système de fichiers racine basé sur SSD.

Si vous utilisez le gouverneur cpu ondemand, essayez d'utiliser celui de performance. Cela aide sur les i7 et a8-3850 de 40 à 50%. Cela ne fait pas beaucoup de différence sur le q9300.

Sur un processeur quad core, vous pourriez faire

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

(L'option -r devrait faire en sorte que vous n'ayez pas à faire cpufreq-set pour chaque cœur, mais sur mes ordinateurs, cela ne fonctionne pas.)

L'option de cache aide encore plus, cependant.

Il existe de nombreux types de ./configurescripts. Il existe des outils populaires ( autconf étant l'un d'entre eux) pour aider un développeur à créer un ./configurescript, mais il n'y a pas de règle qui dit que chaque développeur doit utiliser ces outils, et même parmi ces outils, il peut y avoir de grandes variations dans la façon dont ces scripts sont construits.

Je ne connais aucun ./configurescript populaire pouvant être exécuté en parallèle. La plupart des scripts construits par des outils populaires mettent au moins en cache une partie ou la totalité de leurs résultats, donc si vous l'exécutez à nouveau (sans faire de make cleanpremière, de toute façon), il s'exécute beaucoup plus rapidement la deuxième fois.

Cela ne veut pas dire que cela ne pourrait pas être fait ... mais je soupçonne qu'il y a peu de motivation pour les personnes travaillant autoconf, par exemple, à le faire, car pour la plupart des packages, la phase de configuration est très rapide par rapport à la compilation et à la liaison réelles phases.

Le disque dur est le goulot d'étranglement dans ce cas. Pour accélérer la construction, construisez sur un système avec des disques rapides (lire: temps d'accès bas). Il y a beaucoup de bruit à propos des disques SSD, mais il y a eu des critiques à leur sujet qui n'affectent pas le temps de compilation de manière positive. C'est-à-dire que la construction sur SSD n'était pas tellement plus rapide que sur un lecteur sata décent. Je ne me souviens pas où j'ai lu ceci parce que l'article a quelques années.

Quoi qu'il en soit ... Untar pour éperonner et construire à partir de là.

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

Votre question pourrait même être plus pertinente aujourd'hui, car nous avons des processeurs à douze cœurs avec des performances monocœur (assez) faibles. Les builds automatisés pour l'intégration continue (CI) gaspillent vraiment beaucoup de temps / d'énergie CPU pour chaque commit. Idem avec saut entre les branches.

Donc, passez en revue / lisez mes conseils sur l'accélération de la chose sur https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain .

"Pourquoi faut-il faire les tests de manière séquentielle? ..." Il y a en fait quelques choses qui pourraient être faites en parallèle, tandis que d'autres doivent être séquentielles. Plusieurs choses dépendent de l'environnement de construction - et le script de configuration lui-même est indépendant du système. Il ne contient même pas de bashismes, il fonctionne donc avec un shell POSIX pur.

Si vous voulez écrire un logiciel portable, il n'y a pas d'autre système de construction comme les autotools. Mais si cela ne vous dérange pas de la portabilité (large), évitez les outils automatiques - il existe une pléthore d'outils de construction rapides et suffisamment efficaces.