On Fri, May 15, 2009 at 10:53:53PM +0400, Anton Farygin wrote:
> >Ускорить никак нельзя.  Сейчас структура 
> >расходов времени в girar-builder
> >близка к оптимальной, за исключением 
> >проверки, которая использует
> >--whatprovides.  Эту проверку нужно будет 
> >переделать.  Она выводит много
> >всякой лабуды, но иногда выводит и 
> >кое-что интересное.  Я пока не решил,
> >что именно нам от неё нужно.  Изначально 
> >это была проверка на ничейные
> >каталоги, но проблема ничейных 
> >каталогов никогда не была простой.
> 
> Т.е. - ускорение возможно только 
> увеличением быстродействия каждого из 
> процессорных ядер и добавлением ОЗУ ?

Есть ещё L2/L3 кеш и контроллер памяти.  В дрепперовской статье про
память на с.16 дана такая оценка: доступ к L2/L3 hit стоит 14 циклов
процессора, а L2/L3 miss -- 240 циклов.  Теперь представь что происходит
если ты хочешь параллельно разворачивать несколько чрутов на tmpfs и
выполнять в них интенсивные операции с доступом к памяти.  Они же
толкаются между собой.  То есть линейного распараллеливания на таких
"полгиговых" задачах никогда не будет.  В первом приближении, при
распараллеливании в два потока можно рассчитывать на эффект лишь раза
в полтора.

> И почему бы не включить сборку в 
> несколько потоков ?

Потому что такова семантика сборки заданий: они обладают семантикой
транзакции.  Если задание собрано успешно, то оно переводит репозитарий
в новое состояние, и сборка следующего задания начинается уже на новом
репозитарии.  Нельзя начинать собирать несколько заданий на старом
репозитарии и потом "сводить" несколько результатов сборки в один новый
репозитарий.  Это может закончиться очень плохо.

> >вымывать буферный кеш.  Нельзя просто 
> >так что-то взять и совершенно
> >бесплатно распараллелить.
> 
> Имея под рукой простаивающее железо 
> (например, соседний сервер) ?

Не всякий сервер ликвидной мощностью обладает по современным меркам.
Для быстрой сборки, тем более с распараллеливанием, нужны очень
концентрированные мощности.

> Бесплатного не бывает ничего. Например, 
> время ожидания попадания пакета в сизиф 
> тоже чего-то стоит. Когда одна задача 
> останавливает весь процесс сборки 
> больше чем на сутки - это не правильно, и с 
> этим что-то надо делать.

Да, часами ждать -- это самое неприятное. :(

> Как я понял из твоих слов - добавление 
> железа не решает проблему ?

Железо железу рознь.  Железо на процессорах класса Nehalem Xeon,
к каждому процессору 24 гига памяти, может решить довольно много.