Make, ускорение процесса сборки проектов Опции

[demiurg_spb]

Сегодня попробовал задать мейку во сколько потоков ему работать, т.к. у меня в системе видятся 4 ядра (1+HT)*2 то я задал 4:

Код

make -j 4 all

Результат: проект собрался ровно в 2 раза быстрее!

Спешу поделиться своей радостью со всеми:-)

[klen]

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

[demiurg_spb]

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

А можно-ли как-то из самого мейк-файла передавать мейк-утилите эту же информацию что и аргумент j?

[ReAl]

А можно-ли как-то из самого мейк-файла передавать мейк-утилите эту же информацию что и аргумент j?

Из окружения (и на каждом компе своё), в переменной MAKEFLAGS
(через эту же переменную передаются флаги «вложенным» вызовам $(MAKE) )

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

Так если в файловом менеджере запустить копирование какого-то каталога и тут же чразу его удаление, так тоже весело будет.

Если на -j рассчитывать, то надо бы цель отдельную

Код

rebuild:
    $(MAKE) clean
    $(MAKE)

[AHTOXA]

Если на -j рассчитывать, то надо бы цель отдельную

Код

rebuild:
    $(MAKE) clean
    $(MAKE)

У меня была именно такая цель:

Код

build: clean all

И всё равно с -j получилась ерунда - при первом вызове ничего не произошло (как будто всё up-to date), и лишь при втором начало-таки компилироваться.
Но, что меня удивило больше - скорость компиляции визуально не изменилась. Поэтому я убрал -j, отложив многопоточную сборку до освоения scons (то есть до следующей жизни ).

[ReAl]

У меня была именно такая цель:

Код

build: clean all

И всё равно с -j получилась ерунда - при первом вызове ничего не произошло (как будто всё up-to date), и лишь при втором начало-таки компилироваться.

Конечно, цель-то таки ж не такая.
Тут build зависит от двух других, которые могут и в разном порядке достигаться. Если сначала достигнется all (проверили — всё на месте) и только потом clean (пока то проверялось — составляли список чего тереть), то такой эфект и будет.

Я привёл цель без зависимостей с двумя последовательными действиями, каждое из которых может распараллеливаться, но между ними «точка следования» :-)

Сейчас на ноуте с i3 (два ядра по два потока) типовая команда make -j 4 program, ещё ни разу непоняток из-за кривого порядка не было.

[AHTOXA]

Да, наверняка всё так и есть. Но мне это не нравится.
Часто вижу варианты типа:

Код

all: message_begin elf size message_end

Получается, что все эти варианты тоже будут глючить от многопоточности. Имхо, надо было и в такой перечень целей вставить «точки следования».

[Petka]

Да, наверняка всё так и есть. Но мне это не нравится.
Часто вижу варианты типа:

Код

all: message_begin elf size message_end

Получается, что все эти варианты тоже будут глючить от многопоточности. Имхо, надо было и в такой перечень целей вставить «точки следования».

Банальная безграмотность создателей таких make файлов.

[AHTOXA]

Банальная безграмотность создателей таких make файлов.

Ой ли? Сдаётся мне, что ключ -j появился далеко не сразу. И к этому времени было уже очень много таких вот "безграмотных" мейкфайлов.

[Petka]

Ой ли? Сдаётся мне, что ключ -j появился далеко не сразу. И к этому времени было уже очень много таких вот "безграмотных" мейкфайлов.

Это не причина НЕ исправлять такие makefile.
Раньше и в компиляторах не было volatile. Но это не причина НЕ исправлять старый код.

[AHTOXA]

Это не причина НЕ исправлять такие makefile.
Раньше и в компиляторах не было volatile. Но это не причина НЕ исправлять старый код.

Хорошо хоть, что с этих мейкфайлов снято обвинение в «безграмотности», теперь они просто «старый код»
А теперь представьте, что в следующей версии make введут новый ключик, и вам придётся править все свои мейкфайлы. Имхо, это неправильно. И сравнение с volatile здесь не совсем уместно - в случае make ничто не мешало авторам поставить между субцелями пресловутые «точки следования».