On Fri, May 15, 2009 at 11:05:35PM +0300, Kirill A. Shutemov wrote: > 2009/5/15 Alexey Tourbin : > >> И почему бы не включить сборку в > >> несколько потоков ? > > > > Потому что такова семантика сборки заданий: они обладают семантикой > > транзакции.  Если задание собрано успешно, то оно переводит репозитарий > > в новое состояние, и сборка следующего задания начинается уже на новом > > репозитарии.  Нельзя начинать собирать несколько заданий на старом > > репозитарии и потом "сводить" несколько результатов сборки в один новый > > репозитарий.  Это может закончиться очень плохо. > > Алексей, существует ли относительно недорогой способ выяснить влияют ли > задания друг на друга после, собственно, сборки? Нет такого способа, конечно же. Грубо говоря, у нас есть task1=(1/.git 2/.git) и task2=(1/.git 2/.git). Выяснить, влияют ли эти два задания друга на друга, -- значит научиться предсказывать будущее. То есть предсказывать результат сборки. > Идея в том, что бы запускать задания параллельно, если, по результатам > предыдущих сборок пакетов входящих в задания, есть большая вероятность, С точки зрения такой вероятности можно только предпринимать опережающие спекулятивные сборки. Но это имеет смысл только при избытке ликвидного железа. > На ARM есть возможность сделать сборочную ферму из большого количества > недорогого железа. Но вот без параллелизма всё грустно. Сумма неликвидного желаза не равна единице ликвидного железа: сумма хуже.