[devel] многопоточная сборка
Michael Shigorin
mike на altlinux.org
Чт Апр 4 01:32:37 MSK 2019
On Wed, Apr 03, 2019 at 08:44:02PM +0300, Dmitry V. Levin wrote:
> On Wed, Apr 03, 2019 at 07:09:35PM +0300, Michael Shigorin wrote:
> > python-module-lxml: 26005 99%
> $ grep -F 'elapsed ' beehive/logs/Sisyphus-x86_64/latest/success/python-module-lxml-4.3.3-alt1
> 320.74user 8.13system 8:26.12elapsed 64%CPU (0avgtext+0avgdata 823328maxresident)k
> 330.41user 11.94system 9:13.28elapsed 61%CPU (0avgtext+0avgdata 823328maxresident)k
> На sisyphus_e2k сборка действительно заняла на два порядка
> больше времени, чем на x86? Прискорбно.
Да. Возможно, об этом надо будет повесить отдельный баг.
> > ...из разбора архива заданий для sisyphus_e2k...
> > wesnoth1.12: 24803 99%
> Такого пакета в Сизифе нет.
Архив заданий помнит уже много чего даже тут. :)
> У ближайшего родственного [...]wesnoth-1.14.5-alt2 264%CPU
> сборка выглядит распараллеленной.
Уже радует; хотя пока в процессе сборки наблюдаю скорее единичку,
scons может игнорировать явно заданное -jN?
e804:~> rpm --eval %{?_smp_mflags}
-j32
Надо будет глянуть, не лучше ли покажет себя cmake, который там
тоже в спеке поддержан (но не по умолчанию).
> > samba-DC: 16774 94%
> Такого пакета в Сизифе нет.
Да, их наконец опять объединили.
> > samba: 14355 94%
> [...]samba-4.10.0-alt1 214%CPU
> Сборка выглядит распараллеленной.
Отлично.
> > jfreechart ждёт оптимизированной jvm
> > jfreechart: 10732 88%
> На sisyphus_e2k сборка действительно заняла на два порядка
> больше времени, чем на x86?
Да.
> Вряд ли кто-то затратит много сил на распараллеливание сборки
> пакета, который собирается за 2 минуты.
Там дело в zero vm пока, потому и написал особую оговорку.
Хотя на mipsel примерно так и останется, насколько помню.
> > Mesa: 10110 96%
> Mesa-4:19.0.1-alt1 407%CPU
> Сборка выглядит распараллеленной.
Отлично.
> > python-module-numpy: 7346 98%
> $ grep -F 'elapsed ' beehive/logs/Sisyphus-x86_64/latest/success/python-module-numpy-1:1.15.4-alt1
> 524.30user 22.10system 18:10.31elapsed 50%CPU (0avgtext+0avgdata 381712maxresident)k
> 554.33user 27.57system 19:24.89elapsed 49%CPU (0avgtext+0avgdata 381712maxresident)k
> На этот пакет предлагаю повесить баг.
https://bugzilla.altlinux.org/show_bug.cgi?id=36500
Не очень-то разогнался по сумме, но всё же:
115% cpu 8:16,42 total
(x86_64, для e2k нужен ещё небольшой archdep patch)
> > bouncycastle: 6833 99%
> Сборка выглядит слегка распараллеленной.
> Кроме того, пакет выглядит импортным.
А ещё это java.
> > chicken: 6529 97%
> $ grep -F 'elapsed ' beehive/logs/Sisyphus-x86_64/latest/success/chicken-4.1.0-alt2.1
> 320.75user 10.16system 11:09.34elapsed 49%CPU (0avgtext+0avgdata 309292maxresident)k
> 325.33user 12.28system 11:27.10elapsed 49%CPU (0avgtext+0avgdata 309292maxresident)k
> На этот пакет предлагаю повесить баг.
https://bugzilla.altlinux.org/show_bug.cgi?id=36501
Судя по федоре, 5.0.0 тоже собирается только однопоточно:
https://src.fedoraproject.org/rpms/chicken/blob/master/f/chicken.spec
С объездом а-ля %make_build || make собрался на x86_64
заметно быстрей: 1:30.79elapsed 366%CPU
Применяем?
> Мораль: привлекать внимание коллег нужно, но для этого следует
> использовать релевантные данные. Как мы видим, релевантность
> данных с sisyphus_e2k в данном примере составила 20%.
Я мог убрать java-пакеты, но решил оставить честный head
и не стал убирать тот же lxml, с которым заведомо ничего
так просто не сделать. Ещё хорошо бы добавить данные по
acl для удобства грепанья -- поделишься тем скриптиком?
> Целесообразнее использовать данные тестовой пересборки Сизифа.
Их у меня под рукой вроде бы нет, но затем и предложил в качестве
затравки хотя бы такие скрипты для их разбора. :)
После завершения основных работ по обновлению sisyphus_e2k
поближе к sisyphus/p9 можно будет сделать набег по ним уже
без архива.
--
---- WBR, Michael Shigorin / http://altlinux.org
------ http://opennet.ru / http://anna-news.info
Подробная информация о списке рассылки Devel