Чи можна пришвидшити ./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" часи), це займає набагато більше часу ("real"), оскільки воно не паралельне. Я кілька разів повторював тест (при цьому, можливо, відповідні файли залишаються в кеш-пам'яті), і час знаходиться в межах 10%.

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

Залежно від конкретного сценарію, можливо, існує кілька способів прискорити виконання конфігурації. Наприклад:

• Використовуйте швидшу оболонку. Наприклад, розгляньте використання dashзамість bashяк /bin/sh. (Примітка. Під Debian dashвиправлено такий патч, що configureне використовує його, оскільки використання його розбиває багато configureсценаріїв.)
• Якщо ви запускаєте збірки віддалено (наприклад, через ssh), то я виявив, що вихід консолі може бути досить повільним. Подумайте про дзвінки configure -q.
• Якщо ви неодноразово будуєте один і той же проект, подумайте про використання файлу кеша. Дзвінок configure -C. Докладніше див. Документацію щодо Autoconf.
• Якщо ви будуєте багато різних проектів, спробуйте скористатися файлом сайту ( config.site). Ще раз дивіться документацію.
• Побудуйте паралельно кілька проектів.

Ви розумно користувалися ramdrive для вихідного дерева, але подумайте про це двічі - що робить налаштування? Він виконує свою роботу, перевіряючи не лише своє вихідне дерево , але нерідко і систему доступності бібліотеки, компіляторів і т. Д. У цьому випадку проблема доступу іноді полягає в доступі до диска - у вас це буде набагато швидше, якщо у вас є приклад кореневої файлової системи на основі SSD.

Якщо ви використовуєте керуючий процесор на вимогу, спробуйте скористатися продуктивним. Це допомагає на 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 drive. Я не можу згадати, де я читав цю статтю, оскільки ця стаття - пару років.

У будь-якому випадку ... Untar, щоб протаранити і побудувати звідти.

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:- збільшуючи-швидше-of-GNU- toolchain .

"Чому потрібно робити тести послідовно? ..." Насправді є кілька речей, які можна зробити паралельно, а інші мають бути послідовними. Кілька речей залежать від середовища збирання - і сам сценарій налаштування не залежить від системи. Він навіть не містить башизмів, тому працює з чистою оболонкою POSIX.

Якщо ви хочете написати портативне програмне забезпечення, немає іншої системи побудови, як автоінструменти. Але якщо ви не заперечуєте про (широку) портативність, уникайте автоінструментів - є безліч швидких та досить хороших інструментів збирання.