On Fri, May 15, 2009 at 11:36:14PM +0300, Kirill A. Shutemov wrote: > >> Алексей, существует ли относительно недорогой способ выяснить влияют ли > >> задания друг на друга после, собственно, сборки? > > > > Нет такого способа, конечно же. > > > > Грубо говоря, у нас есть > > task1=(1/.git 2/.git) и > > task2=(1/.git 2/.git). > > > > Выяснить, влияют ли эти два задания друга на друга, -- значит научиться > > предсказывать будущее.  То есть предсказывать результат сборки. > > Я ж написал "после". А. А что тогда такое "влияет"? Единственный рациональный ответ -- что пакеты из одного задания попадают в сборочный чрут при сборке пакетов другого задания. Но что такое "пакеты из задания" "попадают"? Это жаргон для маскировки сути дела. А суть дела в том, что надо сформировать новый репозитарий с пакетами из первого задания и начать собирать второе задание. Это в принципе возвращает нас к сериализации заданий, как оно сейчас реализовано. > >> Идея в том, что бы запускать задания параллельно, если, по результатам > >> предыдущих сборок пакетов входящих в задания, есть большая вероятность, > > > > С точки зрения такой вероятности можно только предпринимать опережающие > > спекулятивные сборки.  Но это имеет смысл только при избытке ликвидного > > железа. > Насколько сложно реализовать этот алгоритм и есть ли он в TODO? Это отчасти реализовано. Когда часть пакетов собралось, а часть не собралось, то при возобновлении задания для первой части будет диагностика "no need to rebuild". См. girar-builder/remote/gb-remote-build. Но это не реализовано в виде, пригодном для спекулятивной сборки. Для спекулятивной сборки нужно несколько нодов. И нужно перделывать task/seq потому что не ясно в каком же статусе эта спекулятивная сборка будет идти. И как поддерживать очередь этих спекулятивных сборок с ходу трудно сказать. В общем, идея гниловатая. :) > В случае ARM, самое производительное, из того, что есть в свободном доступе -- > SheevaPlug: 1.2GHz, 512Mb RAM. Я себе купил две штуки. Буду пробовать собирать. Насколько быстро эта штука будет openoffice собирать? Я боюсь что на таких нативных корытах мы никуда не уедем. В плане придания арму статуса более поддерживаемой архитектуры. > Кстати, а от много ядерного железа при текущей архитектуре прок есть? Нет.