[devel] I: weekend mail

[devel] I: weekend mail

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 257 bytes --]

Hi,

За прошедшие три дня, пока меня не было online, в этот список рассылки
навалилось много корреспонденции.  У меня нет возможности её прочесть,
извините.  Если было что-то важное, напишите всё сначала и по порядку.

Заранее спасибо,


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: weekend mail

[Max Ivanov]

> За прошедшие три дня, пока меня не было online, в этот список рассылки
> навалилось много корреспонденции.  У меня нет возможности её прочесть,
> извините.  Если было что-то важное, напишите всё сначала и по порядку.

Напишу то, что хотел бы чтобы вы прочитали, т.к. считаю это важным

1) Было много предложений и обсуждений как организовать Community
бранч, в  итоге резюме дискуссии можно вычитать в коротком треде
"Бранчи и прочее", который начал E.Ostapets

2) REAL поднял вопрос, что его OpenCascade выкинули из сизифа из-за
более долгой сборки. Это вылилось в обсуждение двух проблем: А) когда
уже включат $NPROCS >1 и Б) как воообще так могло получится, что
человек  старался, делал, а его на Х. послали, он в итоге все свои
наработки склодирует у себя, а в сизиф выливает мелочёвку.

Re: [devel] I: weekend mail

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

On Mon, Sep 07, 2009 at 09:03:34PM +0400, Max Ivanov wrote:
> > За прошедшие три дня, пока меня не было online, в этот список рассылки
> > навалилось много корреспонденции.  У меня нет возможности её прочесть,
> > извините.  Если было что-то важное, напишите всё сначала и по порядку.
> 
> Напишу то, что хотел бы чтобы вы прочитали, т.к. считаю это важным
> 
> 1) Было много предложений и обсуждений как организовать Community
> бранч, в  итоге резюме дискуссии можно вычитать в коротком треде
> "Бранчи и прочее", который начал E.Ostapets

OK, спасибо, я посмотрю.

> 2) REAL поднял вопрос, что его OpenCascade выкинули из сизифа из-за

Вы, наверное, его неправильно поняли.  Пакет opencascade-6.3.0-alt2 в
Сизифе есть, но собирается он существенно дольше, чем монстроидальный
пакет openoffice.org.
Я настоятельно прошу Евгения исправить сборку таким образом, чтобы она
укладывалась в разумные временные рамки.  Я уверен, что этого можно
добиться, но для этого мейнтейнер должен приложить небольшое усилие, а для
этого, в свою очередь, он должен понимать, зачем он отправляет пакеты в
Сизиф, какие выгоды это ему приносит и какую ответственность на него
возлагает.

> более долгой сборки. Это вылилось в обсуждение двух проблем: А) когда
> уже включат $NPROCS >1

Как известно, у этой проблемы есть 2 существенных аспекта:
- Логи сборки, по которым я (и, возможно, кто-то ещё) делаю diff, при
  увеличении $NPROCS становятся несравнимыми, а порой и нечитабельными.
- Неопределённое число пакетов перестанет собираться или, что ещё хуже,
  станет время от времени собираться неправильно.

Я пока не вижу решения первой части проблемы.  Что касается второй, то
заинтересованные могут провести сравнительную пересборку всего Сизифа
с разными значениями $NPROCS и сообщить нам результаты (сравнение по
успешности, затраченному времени, и пр.).

На данный момент мне кажется, что путём распараллеливания выполнения
заданий можно получить лучший результат, чем путём увеличения $NPROCS.

> Б) как воообще так могло получится, что
> человек старался, делал, а его на Х. послали, он в итоге все свои
> наработки склодирует у себя, а в сизиф выливает мелочёвку.

C'est la vie.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] I: weekend mail

[Kirill A. Shutemov]

2009/9/7 Dmitry V. Levin <ldv@altlinux.org>:
> На данный момент мне кажется, что путём распараллеливания выполнения
> заданий можно получить лучший результат, чем путём увеличения $NPROCS.

Дима, а можно по подробней? Какие работы ведутся в этом направлении?

Re: [devel] I: weekend mail

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

On Mon, Sep 07, 2009 at 09:04:05PM +0300, Kirill A. Shutemov wrote:
> 2009/9/7 Dmitry V. Levin <ldv@altlinux.org>:
> > На данный момент мне кажется, что путём распараллеливания выполнения
> > заданий можно получить лучший результат, чем путём увеличения $NPROCS.
> 
> Дима, а можно по подробней? Какие работы ведутся в этом направлении?

Есть некоторые идеи.  Когда два задания собираются параллельно, то одно
из них в конечном счете выбирается жертвой и идёт на второй заход.  Но
на втором заходе, скорее всего, пакеты пересобирать не потребуется.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: weekend mail

[Kirill A. Shutemov]

2009/9/7 Alexey Tourbin <at@altlinux.ru>:
> On Mon, Sep 07, 2009 at 09:04:05PM +0300, Kirill A. Shutemov wrote:
>> 2009/9/7 Dmitry V. Levin <ldv@altlinux.org>:
>> > На данный момент мне кажется, что путём распараллеливания выполнения
>> > заданий можно получить лучший результат, чем путём увеличения $NPROCS.
>>
>> Дима, а можно по подробней? Какие работы ведутся в этом направлении?
>
> Есть некоторые идеи.  Когда два задания собираются параллельно, то одно
> из них в конечном счете выбирается жертвой и идёт на второй заход.  Но
> на втором заходе, скорее всего, пакеты пересобирать не потребуется.

Есть предварительные оценки при каком максимальном количестве потоков
сборки результат будет приемлемым?

Re: [devel] I: weekend mail

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]

On Mon, Sep 07, 2009 at 09:43:17PM +0300, Kirill A. Shutemov wrote:
> 2009/9/7 Alexey Tourbin <at@altlinux.ru>:
> > On Mon, Sep 07, 2009 at 09:04:05PM +0300, Kirill A. Shutemov wrote:
> >> 2009/9/7 Dmitry V. Levin <ldv@altlinux.org>:
> >> > На данный момент мне кажется, что путём распараллеливания выполнения
> >> > заданий можно получить лучший результат, чем путём увеличения $NPROCS.
> >>
> >> Дима, а можно по подробней? Какие работы ведутся в этом направлении?
> >
> > Есть некоторые идеи.  Когда два задания собираются параллельно, то одно
> > из них в конечном счете выбирается жертвой и идёт на второй заход.  Но
> > на втором заходе, скорее всего, пакеты пересобирать не потребуется.
> 
> Есть предварительные оценки при каком максимальном количестве потоков
> сборки результат будет приемлемым?

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

С другой стороны, мы можем кешировать самую дорогую операцию -- сборку
пакетов -- по принципу содержимого сборочного чрута.  Если содержимое
сборочного чрута не изменилось, то пакет пересобирать не надо.

Получается довольно грубая гранулярность: первое задание, которое
успешно завершается, "вышибает" все остальные задания -- они становятся
жертвами и идут на второй заход.  Думаю что на практике в 2-4 потока
собирать можно.

Нельзя ли улучить гранулярность?  Теоретически можно.  То, что
я описываю, можно считать вырожденным случаем transactional memory:
http://en.wikipedia.org/wiki/Software_transactional_memory
Transactional memory означает, что результат сборки задания зависит
только от конечного числа пакетов, которые мы "читаем" во время сборки.
Поэтому в принципе возможны непересекающиеся транзакции.  Но ведь мы ещё
строим транзитивное замыкание!  Это всё портит -- получается, что каждая
транзакция читает весь репозиторий целиком, потому что она строит
транзитивное замыкание.

Короче, на практике гранулярность улучшить нельзя, потому что тогда надо
отслеживать по каким альтернативным переходам строится транзитивное
замыкание.  То есть нельзя отказаться от принципа что первое успешное
задание вышибает все конкурирующие.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] I: weekend mail

[REAL]

Привет!

Давайте всё же с OpenCascade поставим точку, чтобы не возникало трений.

Max Ivanov пишет:
> 2) REAL поднял вопрос, что его OpenCascade выкинули из сизифа из-за
> более долгой сборки. Это вылилось в обсуждение двух проблем: А) когда
> уже включат $NPROCS >1 и Б) как воообще так могло получится, что
> человек  старался, делал, а его на Х. послали, он в итоге все свои
> наработки склодирует у себя, а в сизиф выливает мелочёвку.

Ну, во-первых, мелочёвка в сизиф идёт только в плане графики, что 
касается математики, то, что льётся в сизиф, мелочёвкой назвать тяжело 
(тот же Trilinos мне даже иногда по ночам снится :-D ).

Во-вторых, мне просто давно неинтересна тема 3D-графики в сизифе: 
локально всё давно уже сделано, а переделывать что-то, тратя 
действительно очень большое время на переделку, чтобы всё это было 
пропущено в сизиф, нет ни времени, ни желания, время на месте не 
стоит, и мне заботят немного другие дела. С OCC вопрос давно исчерпан, 
я и Дмитрию приватно, и здесь не раз уже сказал, что судьба этого 
пакета в сизифе меня не интересует, NetGen я сразу по получении письма 
от Дмитрия пересобрал без поддержки OCC, так что не вижу проблемы. К 
тому же сейчас, как я уже говорил, графическими пакетами занялся 
другой человек, надеюсь, у него всё получится.

PS. Ответ Дмитрия на Ваше письмо я видел, всё вполне так, как и было 
уже очевидно раньше: по данному вопросу почвы для взаимодействия нет 
(каждый остаётся при своих), конфликта интересов нет, в итоге и не о 
чем беспокоиться :)

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] I: weekend mail

[Michael Shigorin]

On Mon, Sep 07, 2009 at 09:49:02PM +0400, Dmitry V. Levin wrote:
> - Логи сборки, по которым я (и, возможно, кто-то ещё) делаю diff

Насколько часто?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] I: weekend mail

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

В Втр, 08/09/2009 в 14:47 +0300, Michael Shigorin пишет:
> On Mon, Sep 07, 2009 at 09:49:02PM +0400, Dmitry V. Levin wrote:
> > - Логи сборки, по которым я (и, возможно, кто-то ещё) делаю diff
> 
> Насколько часто?
Я редко делаю дифф, но часто смотрю на логи. Разбираться в логах
многопоточной сборки много неприятнее, чем в логах однопоточной. Поэтому
меня существующая ситуация устраивает, а на своём ноуте, если я знаю,
что не буду смотреть на логи, я могу и побольше --nprocs поставить.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 198 bytes --]