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

6158
netvope

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

26
Это смешно, и позор, что нет хороших инструментов для сборки. Все те, которые существуют, существуют исключительно по инерции. Создание бинарных файлов - такая рискованная, непредсказуемая вещь. Matt Joiner 13 лет назад 3
Он выполняет тесты последовательно, потому что было бы страшно узнать, как выполнить параллелизм в конкретной системе, на которой он работает. Simon Richter 13 лет назад 0

6 ответов на вопрос

11
Peter Eisentraut

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

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

  • Используйте более быструю оболочку. Например, рассмотрите возможность использования dashвместо bashкак /bin/sh. (Примечание: в Debian dashисправлена ​​ошибка, из-за которой configureон не используется, потому что его использование нарушает множество configureсценариев.)
  • Если вы запускаете сборки удаленно (например, через ssh), я обнаружил, что вывод на консоль может быть довольно медленным. Подумайте о звонке configure -q.
  • Если вы неоднократно собираете один и тот же проект, рассмотрите возможность использования файла кэша. Вызов configure -C. Подробности смотрите в документации Autoconf.
  • Если вы строите много разных проектов, подумайте об использовании файла сайта ( config.site). Снова смотрите документацию.
  • Постройте несколько проектов параллельно.
Не могли бы вы объяснить немного больше, почему `make` может распараллеливаться, а` configure` или `autoconf` не могут? netvope 13 лет назад 2
Похоже, у меня есть некоторые проблемы с производительностью оболочки. Выполнение `sh -c" echo $ i "> / dev / null` 1000 раз занимает в этой системе около 10 секунд, а в других системах - только 1-2 секунды. netvope 13 лет назад 0
GNU make использует довольно сложный C-код для запуска и управления несколькими процессами. Сценарии настройки написаны в переносимой оболочке Bourne. Это было бы возможно, но, вероятно, очень сложно. Peter Eisentraut 13 лет назад 1
Сортировка зависимостей между тестами `configure` на самом деле является операцией с низкой сложностью (топологическая сортировка) и была решена в первые дни вычислений. Реальная проблема в том, что никто не удосужился добавить код в autoconf, чтобы сделать это, и тот факт, что многие программисты вручную модифицируют сгенерированные файлы. Вся система должна быть обновлена ​​таким образом, чтобы конфигурация больше не выполнялась сценарием оболочки, а выполнялась с резидентными двоичными файлами метаданных. billc.cn 13 лет назад 3
Пожалуйста, добавьте ссылку на упомянутое обсуждение в список рассылки (ссылка на архив). Karl Richter 9 лет назад 1
3
Flimzy

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

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

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

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

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

К сожалению, похоже, что твердотельные накопители мало чем помогут. Я несколько раз пытался запустить `. / Configure`, но последующие запуски занимают почти столько же времени, сколько и первый. Поскольку в системе много свободной памяти, я думаю, что система запускает компиляторы и библиотеки из кэша памяти, не переходя на диск. netvope 13 лет назад 1
Если вы пытались запустить ./configure несколько раз (и если это сделано autoconf), он должен иметь все результаты в кеше и должен работать очень хорошо. Вы можете опубликовать скрипт конфигурации, чтобы мы посмотрели, если вам нужна дополнительная помощь. Я совершенно уверен, что здесь много гуру bubu 13 лет назад 1
Я на самом деле очистил его между запусками (`. / Configure` всегда выполняется в только что извлеченном исходном дереве). Я собираюсь добавить больше деталей в оригинальном посте (здесь ограничено пространство). netvope 13 лет назад 0
Я только что проверил без очистки папки (т.е. запустил `. / Configure` сразу после другого`. / Configure`), и эти два запуска занимают примерно одинаковое количество времени. Означает ли это, что кеширование не работает на моей системе? netvope 13 лет назад 0
Я возьму coreutils и попробую настроить, когда у меня будет время. Оставайтесь в курсе. bubu 13 лет назад 0
3
Dan Kegel

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

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

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
Спасибо, но я уже компилировал / dev / shm, который является tmpfs :-) netvope 13 лет назад 1
0
Tim Ruehsen rockdaboot

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

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

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

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

Похожие вопросы