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

Question

Чтобы скомпилировать программный пакет на рабочей станции со многими ядрами ЦП (скажем, 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%.

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

Если вы используете регулятор скорости процессора 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 для каждого ядра, но на моих компьютерах это не работает.)

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

Answer 5

В этом случае узким местом является жесткий диск. Чтобы ускорить сборку, соберите систему с быстрыми дисками (читай: малое время доступа). Диски 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

Answer 6

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

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

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

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