Можно ли ускорить ./configure?

Чтобы скомпилировать программный пакет на рабочей станции со многими ядрами ЦП (скажем, 12), этап конфигурации часто занимает намного больше времени, чем этап фактической компиляции, поскольку ./configureвыполняет тесты один за другим, в то же время make -jвыполняет gccпараллельно с другими командами.

Я чувствую, что это огромная трата ресурсов, когда оставшиеся 11 ядер большую часть времени простаивают в ожидании завершения медленной работы ./configure. Почему нужно проводить тесты последовательно? Каждый тест зависит друг от друга? Я могу ошибаться, но похоже, что большинство из них являются независимыми.

Что еще более важно, есть ли способы ускорить ./configure?

Изменить: чтобы проиллюстрировать ситуацию, вот пример с 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

Полученные результаты:

# 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

С coreutils-8.9 , ./configureзанимает в 6 раз больше, чем make. Хотя ./configureиспользуется меньше процессорного времени (посмотрите на «user» и «sys» время), это займет намного больше времени («реальное»), потому что оно не распараллелено. Я повторил тест несколько раз (при этом соответствующие файлы, вероятно, остаются в кеше памяти), и время находится в пределах 10%.

Я вспоминаю обсуждения в списке рассылки Autoconf около 10 лет назад, когда у большинства людей было только одно ядро ​​процессора. Но ничего не было сделано, и я подозреваю, что ничего не будет сделано. Было бы очень сложно настроить все зависимости для параллельной обработки configureи сделать это так, чтобы это было переносимо и надежно.

В зависимости от вашего конкретного сценария, в любом случае может быть несколько способов ускорить запуск конфигурации. Например:

• Используйте более быструю оболочку. Например, рассмотрите возможность использования dashвместо bashкак /bin/sh. (Примечание: в Debian dashисправлены так, что configureон не используется, потому что его использование нарушает множество configureсценариев.)
• Если вы запускаете сборки удаленно (например, через ssh), я обнаружил, что вывод на консоль может быть довольно медленным. Подумайте о звонке configure -q.
• Если вы неоднократно собираете один и тот же проект, рассмотрите возможность использования файла кэша. Вызов configure -C. Подробности смотрите в документации Autoconf.
• Если вы строите много разных проектов, подумайте об использовании файла сайта ( config.site). Снова смотрите документацию.
• Постройте несколько проектов параллельно.

Вы были умны в использовании ramdrive для исходного дерева, но подумайте об этом дважды - что делает configure? Он выполняет свою работу, проверяя не только ваше исходное дерево , но довольно часто и систему на наличие библиотек, компиляторов и т. Д. В этом случае проблема доступа иногда связана с доступом к диску - вы сделаете это намного быстрее, если Пример корневой файловой системы на основе SSD.

Если вы используете регулятор скорости процессора ondemand, попробуйте использовать производительность. Это помогает на i7 и a8-3850 на 40-50%. Не имеет большого значения на Q9300.

На четырехъядерном процессоре вы можете сделать

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

(Опция -r должна сделать так, чтобы вам не приходилось делать cpufreq-set для каждого ядра, но на моих компьютерах это не работает.)

Хотя опция кеша помогает еще больше.

Есть много типов ./configureсценариев. Существуют популярные инструменты ( одним из которых является autconf), помогающие разработчику в создании ./configureсценария, но нет правила, согласно которому каждый разработчик должен использовать эти инструменты, и даже среди этих инструментов могут существовать большие различия в способах этих сценариев. построены.

Мне не известны какие-либо популярные ./configureскрипты, которые можно запускать параллельно. Большинство сценариев, созданных популярными инструментами, по крайней мере кэшируют некоторые или все свои результаты, поэтому, если вы запустите его снова (во make cleanвсяком случае, без первого), во второй раз он будет работать намного быстрее.

Это не значит, что этого нельзя было сделать ... но я подозреваю, что у людей, работающих над этим autoconf, мало мотивации сделать это, поскольку для большинства пакетов фаза конфигурирования очень быстрая по сравнению с фактической компиляцией и компоновкой фазы.

В этом случае узким местом является жесткий диск. Чтобы ускорить сборку, соберите систему с быстрыми дисками (читай: малое время доступа). Диски SSD вызвали много шума, но была высказана некоторая критика по поводу того, что они не влияют на время компиляции в позитивном ключе. То есть сборка на SSD была не намного быстрее, чем на приличном диске SATA. Я не могу вспомнить, где я читал это, потому что статье пару лет.

В любом случае ... Унтар, чтобы таранить и строить оттуда.

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

Ваш вопрос может быть даже более актуальным сегодня, поскольку у нас есть дюжина ядерных процессоров с (довольно) низкой одноядерной производительностью. Автоматизированные сборки для непрерывной интеграции (CI) действительно тратят много времени и энергии процессора на каждый коммит. То же самое со скачками между ветвями.

Поэтому просмотрите / прочитайте мои советы о том, как ускорить процесс, по адресу https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain .

«Почему нужно проводить тесты последовательно? ...» На самом деле есть несколько вещей, которые можно выполнять параллельно, в то время как другие должны быть последовательными. Несколько вещей зависят от среды сборки - и сам скрипт configure не зависит от системы. Он даже не содержит bashisms, поэтому он работает с чистой оболочкой POSIX.

Если вы хотите написать переносимое программное обеспечение, другой системы сборки, такой как autotools, не существует. Но если вы не против (широкой) переносимости, избегайте автоинструментов - есть множество быстрых и достаточно хороших инструментов сборки.