Comments 18
UFO just landed and posted this here
На машинах по два ядра, и судя по статистике из top, в момент сборки были задействованы полностью. Следует заметить что по дефолту distcc позволяет выполнение двух задач на ядро, однако это значение можно сменить в настройках /etc/distcc/hosts. Параметр -j10 был выбран экспериментальным путем. А узким местом я считаю, малый объем памяти, пропускную способность сети и приоритет запуска (NICE).
А так же диски и сама FS может вполне влиять. Так как там куча мелких файлов, то скажем XFS справляется куда шустрее (ReiserFS тоже шустро).
В моей случае на серверах до файловой системы дело не доходит. Задача создает временные файлы в tmpfs, хотя если объем данных будет большой и в размеры tmpfs не поместится… тогда будет задействована файловая система. На клиенте согласен это играет роль, у меня используется ReiserFS. А вот XFS не пробовал для такой задачи, спасибо за идею надо будет попробовать.
Меньшее ускорение от distcc и ccache я бы в первую очередь связал с препроцессингом файлов. ccache кэширует процепроцессированные файлы, поэтому даже при полностью заполненном кэше все равно будет проход препроцессора.
distcc отправляет на сервера компиляции уже препроцессированные файлы (потому что на другой машине совсем другое окружение).
distcc отправляет на сервера компиляции уже препроцессированные файлы (потому что на другой машине совсем другое окружение).
В тегах и в заголовке distss, хотя речь идёт от distcc.
С distcc всё понятно. А вот при чем тут пересборка одного и того же пакета к ccache не понятно. Для ccache подешло бы тестирование с пересборкой одного и того же пакета разных версий. То что вы пересобрали несколько раз один и тот же пакет дает лишь теоретическое максимальное время, а не практическое. В реальности вы пересобираете пакет с разными опциями различной перелинковки разным либтулом и т.д
>разным либтулом и т.д
ccache кэширует только компиляцию объектных файлов, на линковку он не влияет.
>А вот при чем тут пересборка одного и того же пакета к ccache не понятно.
Конкретно данный тест показывает степень максимально возможного ускорения от ccache — когда нет кэш-промахов.
Перекомпиляция малых изменениях полезна при пересборке пакетов в portage, потому что иногда пакеты пересобираются чаще, чем надо. Например, при измении soname у какой-либо библиотеки может потребоваться пересобрать все зависящие от нее пакеты, причем реально потребуется лишь перелинковка, так как объектные файлы не изменятся. Либо же при изменении какого-то USE-флага будет пересобран пакет с большим процентом совпадения собираемых файлов.
При изменении опций компиляции ccache не поможет, так как ccache в кэше хранит предобработанные файлы вместе со всеми опциями компилятора.
ccache кэширует только компиляцию объектных файлов, на линковку он не влияет.
>А вот при чем тут пересборка одного и того же пакета к ccache не понятно.
Конкретно данный тест показывает степень максимально возможного ускорения от ccache — когда нет кэш-промахов.
Перекомпиляция малых изменениях полезна при пересборке пакетов в portage, потому что иногда пакеты пересобираются чаще, чем надо. Например, при измении soname у какой-либо библиотеки может потребоваться пересобрать все зависящие от нее пакеты, причем реально потребуется лишь перелинковка, так как объектные файлы не изменятся. Либо же при изменении какого-то USE-флага будет пересобран пакет с большим процентом совпадения собираемых файлов.
При изменении опций компиляции ccache не поможет, так как ccache в кэше хранит предобработанные файлы вместе со всеми опциями компилятора.
> Как то проснувшись утром пришла мысль проверить эффективность таких инструментов как distss и ccache.
Подъезжая к станции с меня слетела шляпа.
Подъезжая к станции с меня слетела шляпа.
А вывод получается следующий: использование distcc примерно в два раза уменьшает время сборки, а в паре с ccache скорость увеличивается примерно в четыре раза
Какой кошмарный вывод из сумбурного текста.
Сразу надо выкинуть время линковки из ваших замеров, distcc/ccache влияют только на компиляцию препроцессированных исходников. Дальше я говорю только про компиляцию, забудьте про линковку.
tmpfs бесполезен, выигрыша не даст, обычный дисковый кеш работает отлично, сразу забудьте tmpfs.
ccache кеширует препроцессированные исходники с учётом пути. Он очень полезен при компиляции одного продукта несколько раз с разными опциями.
При работе нескольких разработчиков на одной машине (но кеш должен быть всем доступен, что слегка небезопасно) полезен только при таком написании makefile, в котором используются только относительные пути.
Очень полезен в большом проекте с плохо прописанными зависимостями, можно сделать make clean && make objs. Ещё хорошо, когда вы выгружаете 5-6 слабо отличающихся веток в разных директории и всё собираете. Разница легко может быть в сотни раз.
С distcc тоже всё просто: если проект способен собираться в десятки потоков — ускорение будет в десятки раз. Я использовал ccache/distcc на ферме из 100 ядер, ускорение было в 500 раз, по сравнению с одной двухъядерной машиной.
В 500 раз — это за счёт того, что двухъядерная машина была другой архитектуры, а на ферме использовались обычные быстрые intel + cross compiler. Подготовить gcc только для кросс-компиляции без препроцессирования и линковки намного проще.
Опечатки исправьте, пожалуйста. Distcc, а не distss.
>apt-get install distcc
>apt-get install ccache
cэкономит довольно существенное время на перечитывание и обновление базы пакетов.
>apt-get install ccache
apt-get install distcc ccache
cэкономит довольно существенное время на перечитывание и обновление базы пакетов.
что сильно раздражает в distcc — неадаптивный -j (количество потоков) для сборки. В идеале, считал бы его make сам, в зависимости от количества узлов в сети (имеются ввиду подключенные к distcc).
Sign up to leave a comment.
Использование, настройка и тестирование distcc и ccache