Комментарии 12
Подскажите, в чем вы собираете систему? В той же yocto можно в нкстройках указать количество потоков и процессов сборки
Выглядит как заядлый пользователь микроволновок открыл для себя огонь и новые рецепты.
Distcc/tftp/nfs - еще 10 лет назад это уже было банально и никого не удивляло.
https://forum.archive.openwrt.org/viewtopic.php?id=11743 - единственный мануал о том, как подружить OpenWrt с distcc 15-летней давности, который никак нельзя назвать подробным. Рецепт, скорее устаревший, чем новый.
Пока так и не могу разобраться с distcc, да и мотивации пока нет. Наибольший эффект все таки достигается при полной пересборке всего, а это происходит редко. Смотрел презентацию garmin на эту тему, они наладили поток сборки в 180 процессоров и получили прирост около 50-70%(на память). Ограничителем вышли операции конфигурации configure и package проектов.
Если вы про icecream:
то, почему бы не заменить 21 intel i7 одним единственным threadripper 3990x? С трудом представляю, как мне разместить в офисе 21 системник и объединить их в одну сеть.
К сожалению последний раз distcc использовал в начале 2000-х. У нас в лаборатории была куча грустных компов (от 486 до P166MMX, штуки 4-5), но уже был езернет 10мб. И вот сборка ядра была процессом крайне медленным. И вот как раз там коллега distcc и наладил (Санек, привет). Когда вместо одного потока собирается в 4 заметно очень хорошо. Понятно, что сейчас возможно проще найти 64 ядерный проц. С другой стороны если у вас по организации есть десяток 4-8 ядерных компов на которых ничего не происходить (в масштабах тиков ядра) то почему бы всю эту мощь не утилизировать совершенно бесплатно?
Забавно, консоль "недружелюбная", но вся статья про консольные средства.
Погуглив, выяснилось, что такое случается, - нестабильность при многоядерной работе.
Сомнительная формулировка. Звучит как будто плохие многоядерные процессоры все ломают. Чаше всего в таких случаях проблема в сборочных скриптах, например какая-нибудь зависимость не указана и про последовательной сборки все замечательно, а когда параллельно все собирается сборка "А" запускает параллельно с "Б", и "А" нужно "Б" но система сборки об этом не знает и сборка проваливается. И это к сожалению хороший сценарий, плохой сценарий когда "Б" берется с предыдущего раза, и у тебя все собирается но бинарник не соответствует коду. Лучше чинить систему сборки таких пакетов, а не добавлять костыли. Или хотя бы насильно включать им сразу последовательную сборку, а не пытаться в несколько потоков собирать, а потом откатываться на последовательную сборку.
Ускорение процесса разработки под Embedded Linux