Как определить максимальное число, которое нужно передать в опцию make -j?

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

Компиляция 100 крошечных файлов C может быть быстрее, чем компиляция одного огромного файла, или наоборот. Создание небольшого, очень запутанного кода может быть медленнее, чем создание огромного количества прямого / линейного кода.

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

Также есть аспект правильности спецификации сборки. Очень сложные сборки могут иметь условия гонки, вызывающие периодические сбои сборки, частота возникновения которых может сильно варьироваться с увеличением или уменьшением j-фактора.

Я могу продолжать и продолжать. Дело в том, что вы должны фактически оценить вашу сборку в вашем самом контексте , для которого вы хотите оптимизировать коэффициент j. Комментарий @Jeff Schaller применяется: повторяйте, пока не найдете свой лучший вариант. Лично я бы начал со значения nproc, сначала пробовал бы вверх и вниз, только если попытки вверх показывают немедленную деградацию.

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

Наконец, ИМХО, лучше использовать (адаптивный) сервер заданий , если он поддерживается и доступен, вместо фиксированного коэффициента j - он постоянно обеспечивает лучшую производительность сборки в более широком диапазоне контекстов.

Самый прямой -путь вперед — это использовать nprocвот так:

make -j`nproc`

Команда nprocвернет количество ядер на вашем компьютере. Оборачивая его в тики, команда nprocбудет выполняться первой, возвращать число, и это число будет передано в make.

У вас может быть неподтвержденный опыт, когда выполнение -count + 1 приводит к более быстрому времени компиляции. Это больше связано с такими факторами, как задержки ввода-вывода, задержки других ресурсов и другие ограничения доступности ресурсов.

Чтобы сделать это с nproc+1, попробуйте это:

make -j$((`nproc`+1))

Если вы хотите написать команду make, чтобы использовать столько параллельных рабочих процессов, сколько у вас есть виртуальных процессоров, я предлагаю использовать:

nproc | xargs -I % make -j%

Которая может быть записана либо как отдельная команда, либо как директива RUNвнутри Dockerfile(, поскольку Docker не поддерживает вложенные команды)

lscpu | grep "^CPU(" | awk '{print $2}'

Это даст вам количество ядер ЦП.

Я написал инструмент под названиемmakeMax , который запускает make с оптимальным количеством заданий и нагрузкой. На основе лучших ответов, которые я нашел здесь.