Re: [devel] size_time_regression

Re: [devel] size_time_regression

[Damir Shayhutdinov]

02.06.06, Alexey Tourbin<at@altlinux.ru> написал(а):
> Пока не забыл.  Есть ещё несколько идей.
> Положительное содержание: пакет можно персобрать в среднем менее чем за минуту.
> Желающие могут построить доверительный интервал.  Суммарная девиация (СКО)
> выборки уменьшается в $\frac1{\sqrt N}$ раз.

Мне кажется, если разделить пакеты по языкам, необходимым для их
сборки (C++, C, Python, Java, Ocaml, haskell, erlang etc), то разброс
внутри отдельной группы может быть гораздо меньше.

Re: [devel] size_time_regression

[Alexey Tourbin]

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

On Fri, Jun 02, 2006 at 06:47:56PM +0400, Damir Shayhutdinov wrote:
> 02.06.06, Alexey Tourbin<at@altlinux.ru> написал(а):
> > Пока не забыл.  Есть ещё несколько идей.
> > Положительное содержание: пакет можно персобрать в среднем менее чем за минуту.
> > Желающие могут построить доверительный интервал.  Суммарная девиация (СКО)
> > выборки уменьшается в $\frac1{\sqrt N}$ раз.
> 
> Мне кажется, если разделить пакеты по языкам, необходимым для их
> сборки (C++, C, Python, Java, Ocaml, haskell, erlang etc), то разброс
> внутри отдельной группы может быть гораздо меньше.

Флаг в руки! :)  Сама постановка задачи (функция времени сборки от
_размера_ src.rpm) не является достаточно обоснованной.  То есть можно
оценивать время сборки не исходя из размера пакета, а, допустим, исходя
из первой буквы имени maintainer'а.  Не факт, что результат будет хуже.

Просто сейчас (или "тогда"?) сборочная среда beehive сорирует пакеты для
пересборки по размеру (в первую очередь пересобирает большие пакеты, а
потом уже маленькие, в надежде на некую сходимость процесса), что
представляется разумным, ибо
$\lim_{\mathrm{size}\to0}\mathrm{time}\to0$.

Но из этого предела ещё не следует никакой регрессии.

То есть *можно* оценить некоторые величины, которые сделают инкрементную
пересборку сизифа более возможной, с точки зрения ограничений на ресурсы
(на время).  Опять же, ниоткуда не следует, что *нужно* произвести эти
оценки и вообще что инкрементная пересборка нужна.

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

Re: [devel] size_time_regression

[Denis Ovsienko]

> Рисунок приложен.  Легко видеть, что линейная регрессия не удалась.
> То есть видно, что маленькие пакеты собираются быстро, а большие
> пакеты могут собираться как быстро, так и медленно.  То есть имеется
> специфическая автокрреляция.  Условия Гаусса-Маркова не выполняются,
> поэтому наибольшее правдоподобие (в частности, МНК-регрессию) вообще
> применять нельзя.
Глядя на график в разных масштабах, возникает несколько замечаний:
1. Какие именно небольшие пакеты требуют большого времени сборки?
2. Определённая регрессия (область сгущения под углом градусов в 70) всё
же видна.
3. Действительно нужно проводить анализ внутри групп, потому что сборка
10 мегабайт готовых картинок и сборка 10 мегабайт исходного кода
принципиально отличаются.
4. Область сгущения, скорее всего, сформирована пакетами, требующими
компиляции.

-- 
    DO4-UANIC

Re: [devel] size_time_regression

[Alex V. Myltsev]

Alexey Tourbin wrote:
> Сама постановка задачи (функция времени сборки от
> _размера_ src.rpm) не является достаточно обоснованной.
Как я понимаю, необоснованность этой задачи вы и показали
экспериментально, да?

А я вот матстатистики не помню, конечно, но я бы оценивал время
пересборки пакета исходя из времени его предыдущей пересборки.
Можно взять два набора логов (от разных сборок) и проверить регрессию?

Re: [devel] size_time_regression

[Ivan Fedorov]

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

Alex V. Myltsev пишет:
> Alexey Tourbin wrote:
>> Сама постановка задачи (функция времени сборки от
>> _размера_ src.rpm) не является достаточно обоснованной.
> Как я понимаю, необоснованность этой задачи вы и показали
> экспериментально, да?
> 
> А я вот матстатистики не помню, конечно, но я бы оценивал время
> пересборки пакета исходя из времени его предыдущей пересборки.
> Можно взять два набора логов (от разных сборок) и проверить регрессию?

А учитывая тот факт, что это ПЕРЕсборки, у нас гарантированно будет
хотябы одна удачная сборка...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]