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

29

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

— netvope
источник

4

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

— Мэтт Джоунер

Он выполняет тесты последовательно, потому что было бы страшно узнать, как выполнить параллелизм в конкретной системе, на которой он работает.

— Саймон Рихтер

13

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

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

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

— Питер Айзентраут
источник

2

Не могли бы вы объяснить немного больше , почему makeможно распараллелить , но configureили autoconfне может?

— netvope

Похоже, у меня есть некоторые проблемы с производительностью оболочки. Выполнение sh -c "echo $i" > /dev/null1000 раз занимает около 10 секунд в этой системе, но только 1-2 секунды в других моих системах.

— netvope

1

GNU make использует довольно сложный C-код для запуска и управления несколькими процессами. Сценарии настройки написаны в переносимой оболочке Bourne. Это было бы возможно, но, вероятно, очень сложно.

— Питер Айзентраут

4

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

— billc.cn

1

Пожалуйста, добавьте ссылку на упомянутое обсуждение в список рассылки (ссылка на архив).

— Карл Рихтер

3

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

— бубу
источник

1

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

— netvope

1

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

— бубу

Я на самом деле очистил его между запусками ( ./configureвсегда работает в только что извлеченном исходном дереве). Я собираюсь добавить больше деталей в оригинальном посте (здесь ограничено пространство).

— netvope

Я только что проверил без очистки папки (т.е. работает ./configureсразу после другого ./configure), и два запуска занимают примерно одинаковое количество времени. Означает ли это, что кеширование не работает в моей системе?

— netvope

Я возьму coreutils и попробую настроить, когда у меня будет время. Следите за обновлениями.

— бубу

3

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

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

— Дэн Кегель
источник

3

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

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

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

— Flimzy
источник

2

Однако для использования этих инструментов есть веская причина: они зрелые и отслеживают множество мелких деталей. Я думаю, что Linux не будет в таком хорошем положении во встроенном мире, если вы не сможете просто указать скрипт конфигурации на свой кросс-компилятор и заставить его работать «из коробки» 90% времени.

— Саймон Рихтер

2

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

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

1

Спасибо, но я уже компилировал / dev / shm, который является tmpfs :-)

— netvope

0

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

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

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

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

— Тим Рюхсен Rockdaboot
источник