LINUX.ORG.RU

можно ли распараллелить make?

 , , ,


0

1

у меня при сборке make не всегда параллелит задачи, даже если указываю -j. сама компиляция происходит быстро - с задействованием всех ядер. но долго ожидать конфигурирования. соизмеримо со временем компиляции, если не превосходит. (имею ввиду «простои» ядер ЦП подолгу, когда пишет «checking for...» и задействовано лишь одно ядро). как можно ускорить и распараллелить эти этапы (autoconf/configure) на многоядерном процессоре?



Последнее исправление: xakepp35 (всего исправлений: 2)

Ответ на: комментарий от RazrFalcon

да. если проект большой, например buildroot - то компилишь 30% времени а 70% ждёшь, пока однопоточный конфигуратор «тупит» - видно что пока все эти миллиарды «checking for sanity/insanity...» происходят - задействовано только одно ядро :) как лечить?

xakepp35
() автор топика

Использовать CMake. Впрочем, эскобар.жпг

Deleted
()

Кэш конфига. Ноэтонеточно.

mos ★★☆☆☆
()
Ответ на: комментарий от deadNightTiger

такие перспективы печалят меня.. что неужели за всё это время с появлением многоядерных процессоров никто не задумался о распараллеливании этого дела?

xakepp35
() автор топика
Ответ на: комментарий от xakepp35

посчитайте мне сколько будет 2+x при условии что x вы не знаете ?
конфигураторов линейная логика, каждое выражение выводится из результатов предыдущего, это нельзя распараллелить
в компиляции, настройка конфигов это 1-3% времени, и оно не существенно

anonymous
()

make к конфигурации не имеет никакого отношения

Harald ★★★★★
()

Не понятно, это разные проекты собираются или один много раз? Есть кеширование, как уже сказали, но в общем случае аноним прав, это просто нельзя распараллелить из-за зависимостей между проверками.

xaizek ★★★★★
()

Выкинь автолулзы. Это единственный способ.

hateyoufeel ★★★★★
()

autismtools никак не исправить.

a1batross ★★★★★
()

Вы смешали всё в одну кучу. configure это одно, make - другое. Нет, configure нельзя распараллелить, ибо это autocrap. Да обычно и не нужно, я не припомню проектов где оно выполнялось бы дольше десятка секунд. Конечно же оно несоизмеримо со временем компиляции сколь либо крупного проекта.

slovazap ★★★★★
()
Ответ на: комментарий от RazrFalcon

Используйте нормальные системы сборки, а не говно мамонта.

это про тупящий cmake ? так он также при конфигурации работает. это не возможно расспраралелить просто.

а с учетом того что cmake не проверяет вообще ничего, так и говорить нечего, ну да, стильно модно молодежно.

alwayslate ★★
()
Ответ на: комментарий от anonymous

посчитайте мне сколько будет 2+x при условии что x вы не знаете ?

Пока точное значение не нужно, можно считать что ответ y. Причем y = 2+x (или y = f(x))

KennyMinigun ★★★★★
()
Ответ на: комментарий от KennyMinigun

да ну ? ну тогда вам и автоконфг запускать не нужно, он то считай результат выводит и не формулы упрощает

anonymous
()
Ответ на: комментарий от xakepp35

да. если проект большой, например buildroot - то компилишь 30% времени а 70% ждёшь, пока однопоточный конфигуратор «тупит»

Лучше всего, конечно, один раз сделать configure, а потом пересобирать с готовой конфигурацией. Или там Makefile вызывает configure каждый раз?

proud_anon ★★★★★
()
Ответ на: комментарий от Harald

покажи мне «нормальные системы»

Сейчас вполне себе нормальным является meson. Распараллеливания конфигурации там тоже нет, НЯЗ, но работает шустро.

Deleted
()
Ответ на: комментарий от xakepp35

даже если указываю -j
например buildroot

На первых страницах документации

Buildroot quick start
You should never use make -jN with Buildroot: top-level parallel make is currently not supported.

то компилишь 30% времени а 70% ждёшь

Ну это ты преувеличиваешь. Возможно ты включаешь сюда время скачивания пакетов.

Хотя вопрос остается. Даже make source он выполняет последовательно. А с учетом того, что иногда используются тормозные зеркала (больше касается стронних сборок builroot-а), это жесть.

Наверное можно, разобравшись в выхлопе make graph-depends, запустить несколько make <pkg>-build для независимых пакетов (я не пробовал).

arson ★★★★★
()
Ответ на: комментарий от KennyMinigun

то есть вы можете про оптимизировать автоконф для параллельного выполнения ? ждем от вас результатов

anonymous
()
Ответ на: комментарий от arson

разобравшись в выхлопе make graph-depends

Какая-то лажа в этом выхлопе :(
Из него следует, что toolchain нужен, просто потому, что нужен.

arson ★★★★★
()
Ответ на: комментарий от anonymous

то есть вы можете про оптимизировать автоконф для параллельного выполнения ?

Могу

ждем от вас результатов

ждем от вас аванса.

KennyMinigun ★★★★★
()

Meson попробуй.

EXL ★★★★★
()
Ответ на: комментарий от Deleted

Распараллеливания конфигурации там тоже нет, НЯЗ, но работает шустро.

Оно там и не нужно, там конфигурация делается молниеносно, это же не aut*crap с его кучей проверок из прошлого века вроде:

checking for memcpy() in string.h...
checking for sin() in math.h...
checking for benis() in vagina.h...

Которые только диск насилуют. Плюс ещё всякие припарки, вроде libtool и т. д.

EXL ★★★★★
()

как можно ускорить

--config-cache, например.

devl547 ★★★★★
()
Ответ на: комментарий от EXL

эти все проверки туда люди руками зачем-то напихали, автотулз не принуждает проверять наличие memcpy и пениса в вагине

Harald ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.