[devel] Сборка python3 в Сизифе работает медленно

[devel] Сборка python3 в Сизифе работает медленно

[Denis Kirienko]

Добрый день!

На протяжении двух-трех лет я ждал появления python3 в Сизифе,
поставил его сразу же после появления, но когда дело дошло до
реального использования сразу же выяснилось, что сизифная сборка
третьего питона работает медленно.

Что я имею - установленный пакет python3, и установленный в
/usr/local/bin собранный локально из тарбола python3 (./configure &&
make && make install).

Для замера быстродействия питона использовалась следующая простая
программа test.py:

A = [i for i in range(3 * 10 ** 7)]
print(sum(A))


Вот результаты на одном компьютере (система - p6, i586):

$ time /usr/bin/python3 test.py
449999985000000
6.48user 0.54system 0:07.11elapsed 98%CPU (0avgtext+0avgdata
2408448maxresident)k
0inputs+0outputs (0major+149843minor)pagefaults 0swaps

$ time /usr/local/bin/python3 test.py
449999985000000
4.07user 0.50system 0:04.58elapsed 99%CPU (0avgtext+0avgdata
2404352maxresident)k
0inputs+0outputs (0major+149726minor)pagefaults 0swaps

Вот - другой компьютер, менее мощный, тоже i586, Сизиф:

[dk@phobos ~]$ time /usr/bin/vitty@altlinux.rupython3 test.py
449999985000000
10.68user 0.67system 0:11.36elapsed 99%CPU (0avgtext+0avgdata
2420736maxresident)k
0inputs+0outputs (0major+141536minor)pagefaults 0swaps

[dk@phobos ~]$ time /usr/local/bin/python3 test.py
449999985000000
6.15user 0.63system 0:07.75elapsed 87%CPU (0avgtext+0avgdata
2404352maxresident)k
5120inputs+0outputs (15major+141522minor)pagefaults 0swaps

То есть в каждом случае сизифный пакет работает более, чем в полтора
раза медленнее, чем самособранный из тарбола.

В чем может быть причина? Может быть, -O3 при сборке пакета не включено?

--
Денис

Re: [devel] Сборка python3 в Сизифе работает медленно

[Vitaly Kuznetsov]

Добрый день,

On Sun, 25 Mar 2012 22:24:37 +0400, Denis Kirienko wrote:
> Добрый день!
>
> На протяжении двух-трех лет я ждал появления python3 в Сизифе,
> поставил его сразу же после появления, но когда дело дошло до
> реального использования сразу же выяснилось, что сизифная сборка
> третьего питона работает медленно.

спасибо за информацию, давайте попробуем поразбираться.
На x86_64 разница не так заметна, но есть:

Системный:
$ time python3 /tmp/test.py
449999985000000
python3 /tmp/test.py  6,06s user 2,35s system 68% cpu 12,309 total

Локально собранный:
$ time ./python /tmp/test.py
449999985000000
./python /tmp/test.py  5,17s user 1,69s system 99% cpu 6,898 total

>
> В чем может быть причина? Может быть, -O3 при сборке пакета не 
> включено?

Я попробовал сделать сборку с -O3. Изменение времени работы примера 
достигается крайне незначительное, в пределах статистической 
погрешности. Проблема, вероятно, в чём-то ещё.

Re: [devel] Сборка python3 в Сизифе работает медленно

[Vitaly Kuznetsov]

On Mon, 26 Mar 2012 16:06:52 +0400, Vitaly Kuznetsov wrote:
> Добрый день,
>
>>
>> В чем может быть причина? Может быть, -O3 при сборке пакета не 
>> включено?
>
> Я попробовал сделать сборку с -O3. Изменение времени работы примера
> достигается крайне незначительное, в пределах статистической
> погрешности. Проблема, вероятно, в чём-то ещё.
>

Наибольший из всех наших парметров сборки вклад вносит 
"--enable-shared"

Re: [devel] Сборка python3 в Сизифе работает медленно

[Андрей Черепанов]

[-- Attachment #1: Type: Text/Plain, Size: 967 bytes --]

26 марта 2012 Vitaly Kuznetsov написал:
> Добрый день,
> 
> On Sun, 25 Mar 2012 22:24:37 +0400, Denis Kirienko wrote:
> > Добрый день!
> >
> > На протяжении двух-трех лет я ждал появления python3 в Сизифе,
> > поставил его сразу же после появления, но когда дело дошло до
> > реального использования сразу же выяснилось, что сизифная сборка
> > третьего питона работает медленно.
> 
> спасибо за информацию, давайте попробуем поразбираться.
> На x86_64 разница не так заметна, но есть:
> 
> Системный:
> $ time python3 /tmp/test.py
> 449999985000000
> python3 /tmp/test.py  6,06s user 2,35s system 68% cpu 12,309 total
> 
> Локально собранный:
> $ time ./python /tmp/test.py
> 449999985000000
> ./python /tmp/test.py  5,17s user 1,69s system 99% cpu 6,898 total
6,06*68% = 4,12 c.
5,17*99% = 5,11 c. С учётом загрузки процессора первый вариант более 
экономичен и эффективен. Второй слишком агрессивно поедает ресурсы.

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Сборка python3 в Сизифе работает медленно

[Anton Gorlov]

27.03.2012 0:39, Андрей Черепанов написал:
>> Системный:
>> >  $ time python3 /tmp/test.py
>> >  449999985000000
>> >  python3 /tmp/test.py  6,06s user 2,35s system 68% cpu 12,309 total
>> >
>> >  Локально собранный:
>> >  $ time ./python /tmp/test.py
>> >  449999985000000
>> >  ./python /tmp/test.py  5,17s user 1,69s system 99% cpu 6,898 total
> 6,06*68% = 4,12 c.
> 5,17*99% = 5,11 c. С учётом загрузки процессора первый вариант более
> экономичен и эффективен. Второй слишком агрессивно поедает ресурсы.

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

Re: [devel] Сборка python3 в Сизифе работает медленно

[Vitaly Kuznetsov]

On Tue, 27 Mar 2012 09:17:42 +0400, Anton Gorlov wrote:
> 27.03.2012 0:39, Андрей Черепанов написал:
>>> Системный:
>>> >  $ time python3 /tmp/test.py
>>> >  449999985000000
>>> >  python3 /tmp/test.py  6,06s user 2,35s system 68% cpu 12,309 
>>> total
>>> >
>>> >  Локально собранный:
>>> >  $ time ./python /tmp/test.py
>>> >  449999985000000
>>> >  ./python /tmp/test.py  5,17s user 1,69s system 99% cpu 6,898 
>>> total
>> 6,06*68% = 4,12 c.
>> 5,17*99% = 5,11 c. С учётом загрузки процессора первый вариант более
>> экономичен и эффективен. Второй слишком агрессивно поедает ресурсы.
>
> Ну.. выяснить всё равно было бы интересно почему оно так.
> А так - иной раз лучше что бы задача выполнилась быстрее, чем их
> весело множество в очереди имхо.

Всё достаточно просто: питон, собранный с разделяемой библиотекой, 
работает медленней. На i586 это более заметно, чем на x86_64. Сделать с 
этим что-то сложно: собирать без библиотеки не хочется. Думаю, что 
оставить всё как есть будет меньшим злом.

Re: [devel] Сборка python3 в Сизифе работает медленно

[Konstantin Pavlov]

On Tue, Mar 27, 2012 at 10:02:06AM +0400, Vitaly Kuznetsov wrote:
> > Ну.. выяснить всё равно было бы интересно почему оно так.
> > А так - иной раз лучше что бы задача выполнилась быстрее, чем их
> > весело множество в очереди имхо.
> 
> Всё достаточно просто: питон, собранный с разделяемой библиотекой, 
> работает медленней. На i586 это более заметно, чем на x86_64. Сделать с 
> этим что-то сложно: собирать без библиотеки не хочется. Думаю, что 
> оставить всё как есть будет меньшим злом.

Предлагаю и ruby собрать без 9c75a2ae3072.

-- 
Konstantin Pavlov
VideoLAN team

Re: [devel] Сборка python3 в Сизифе работает медленно

[Denis Kirienko]

> Всё достаточно просто: питон, собранный с разделяемой библиотекой, работает
> медленней. На i586 это более заметно, чем на x86_64. Сделать с этим что-то
> сложно: собирать без библиотеки не хочется. Думаю, что оставить всё как есть
> будет меньшим злом.

Понятно, но мне это важно, замедление в полтора раза меня
категорически не устраивает.

Тогда придется самому собирать пакет без  --enable-shared

Наверное, с python2 история такая. Подскажите (не специалист), если я
возьму пакеты с python версии 2, пересоберу без --enable-shared, и
заменю системные пакеты с питоном на пересобранные, в системе
что-нибудь сломается?

--
Денис

Re: [devel] Сборка python3 в Сизифе работает медленно

[Vitaly Kuznetsov]

On Tue, 27 Mar 2012 18:54:11 +0400, Denis Kirienko wrote:
>> Всё достаточно просто: питон, собранный с разделяемой библиотекой, 
>> работает
>> медленней. На i586 это более заметно, чем на x86_64. Сделать с этим 
>> что-то
>> сложно: собирать без библиотеки не хочется. Думаю, что оставить всё 
>> как есть
>> будет меньшим злом.
>
> Понятно, но мне это важно, замедление в полтора раза меня
> категорически не устраивает.
>

На x86_64, как я уже сказал, разница меньше.

> Тогда придется самому собирать пакет без  --enable-shared
>
> Наверное, с python2 история такая. Подскажите (не специалист), если я
> возьму пакеты с python версии 2, пересоберу без --enable-shared, и
> заменю системные пакеты с питоном на пересобранные, в системе
> что-нибудь сломается?

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

Re: [devel] Сборка python3 в Сизифе работает медленно

[Michael Shigorin]

On Tue, Mar 27, 2012 at 07:00:05PM +0400, Vitaly Kuznetsov wrote:
> >Тогда придется самому собирать пакет без  --enable-shared
> Некоторые программы линкуются с этими разделяемыми
> библиотеками. Если у вас в системе их нет, то вы можете так
> поступить.

Может, собирать питон дважды -- ради библиотеки стороннему
софту и одним куском исполняемый бинарник?

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

Re: [devel] Сборка python3 в Сизифе работает медленно

[Vitaly Kuznetsov]

On Tue, 27 Mar 2012 20:03:56 +0300, Michael Shigorin wrote:
> On Tue, Mar 27, 2012 at 07:00:05PM +0400, Vitaly Kuznetsov wrote:
>> >Тогда придется самому собирать пакет без  --enable-shared
>> Некоторые программы линкуются с этими разделяемыми
>> библиотеками. Если у вас в системе их нет, то вы можете так
>> поступить.
>
> Может, собирать питон дважды -- ради библиотеки стороннему
> софту и одним куском исполняемый бинарник?

У нас использован подход с shared из Fedora. А в Debian как раз 
собирают static + либа отдельно. Давайте попробуем и у нас так 
поступить.

Re: [devel] Сборка python3 в Сизифе работает медленно

[Vitaly Kuznetsov]

On Wed, 28 Mar 2012 13:49:59 +0400, Vitaly Kuznetsov wrote:
> On Tue, 27 Mar 2012 20:03:56 +0300, Michael Shigorin wrote:
>> On Tue, Mar 27, 2012 at 07:00:05PM +0400, Vitaly Kuznetsov wrote:
>>> >Тогда придется самому собирать пакет без  --enable-shared
>>> Некоторые программы линкуются с этими разделяемыми
>>> библиотеками. Если у вас в системе их нет, то вы можете так
>>> поступить.
>>
>> Может, собирать питон дважды -- ради библиотеки стороннему
>> софту и одним куском исполняемый бинарник?
>
> У нас использован подход с shared из Fedora. А в Debian как раз
> собирают static + либа отдельно. Давайте попробуем и у нас так
> поступить.

В http://git.altlinux.org/tasks/67991/ Python3 собран статически. 
Просьба проверить скорость работы, особенно интересен результат на i586.

Re: [devel] Сборка python3 в Сизифе работает медленно

[Denis Kirienko]

Добрый вечер!

> В http://git.altlinux.org/tasks/67991/ Python3 собран статически. Просьба
> проверить скорость работы, особенно интересен результат на i586.

Спасибо,

вот что у меня получилось (выбран один случайный запуск из серии):

Локальная сборка из тарбола:
6.25user 0.66system 0:06.92elapsed 99%CPU (0avgtext+0avgdata
2404352maxresident)k
0inputs+0outputs (0major+141499minor)pagefaults 0swaps

python3-3.2.2-alt3:
9.97user 0.62system 0:10.61elapsed 99%CPU (0avgtext+0avgdata
2416640maxresident)k
0inputs+0outputs (0major+141310minor)pagefaults 0swaps

python3-3.2.2-alt4:
7.01user 0.66system 0:07.69elapsed 99%CPU (0avgtext+0avgdata
2408448maxresident)k
840inputs+0outputs (14major+140725minor)pagefaults 0swaps

Если взять несколько запусков, то результаты будут примерно такими же,
python3-3.2.2-alt4 примерно на 10-15% медленнее, чем сборка из
тарбола, что уже вполне приемлемо.

Думаю, что так и надо поступить.

Естественный вопрос - а нельзя ли поступить аналогично c python2 в
Сизифе, например?

--
Денис

Re: [devel] Сборка python3 в Сизифе работает медленно

[Vitaly Kuznetsov]

On Wed, 28 Mar 2012 21:24:20 +0400, Denis Kirienko wrote:
>
> python3-3.2.2-alt4 примерно на 10-15% медленнее, чем сборка из
> тарбола, что уже вполне приемлемо.
>
> Думаю, что так и надо поступить.

Ок, так и поступим.

>
> Естественный вопрос - а нельзя ли поступить аналогично c python2 в
> Сизифе, например?

Можно, завтра попробую.

Re: [devel] Сборка python3 в Сизифе работает медленно

[Dmitry V. Levin]

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

On Wed, Mar 28, 2012 at 09:24:20PM +0400, Denis Kirienko wrote:
> Естественный вопрос - а нельзя ли поступить аналогично c python2 в
> Сизифе, например?

Надо замерить разницу в производительности, возможно, для python2 она не
такая как для python3.  Вообще, когда разница в один регистр так сильно
влияет на результат, это свидетельство плохой оптимизации в реализациях
python.  Обычные программы на C тоже дают разницу, и для некоторых
программ, таких как bzip2 и xz, ее несложно замерить, но она обычно
меньше 5%.


-- 
ldv

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

Re: [devel] Сборка python3 в Сизифе работает медленно

[Denis Kirienko]

Доброе утро!

> Надо замерить разницу в производительности, возможно, для python2 она не
> такая как для python3.

Ну у меня на одном компьютере получилось так (i586, p6 - это та
машина, для которой были первые данные по замерам python3 в первом
моем письме).

python-2.6.6-alt4:
$ time /usr/bin/python test.py
449999985000000
10.22user 0.46system 0:10.73elapsed 99%CPU (0avgtext+0avgdata
2363392maxresident)k
40inputs+0outputs (1major+157036minor)pagefaults 0swaps

python-2.6.6 из тарбола:
[dk@server ~]$ time /usr/local/bin/python test.py
449999985000000
7.85user 0.43system 0:08.30elapsed 99%CPU (0avgtext+0avgdata
2363392maxresident)k
16inputs+0outputs (0major+156995minor)pagefaults 0swaps

То есть разница около 30%.

--
Денис

Re: [devel] Сборка python3 в Сизифе работает медленно

[Vitaly Kuznetsov]

On Thu, 29 Mar 2012 10:56:44 +0400, Denis Kirienko wrote:
> Доброе утро!
>
>> Надо замерить разницу в производительности, возможно, для python2 
>> она не
>> такая как для python3.
>
> Ну у меня на одном компьютере получилось так (i586, p6 - это та
> машина, для которой были первые данные по замерам python3 в первом
> моем письме).
>

Потестируйте, пожалуйста, на i586 http://git.altlinux.org/tasks/68027/ 
(если сможете т.к. нужен Сизиф).

Re: [devel] Сборка python3 в Сизифе работает медленно

[Denis Kirienko]

Добрый вечер!

> Потестируйте, пожалуйста, на i586 http://git.altlinux.org/tasks/68027/ (если
> сможете т.к. нужен Сизиф).

Протестировал на одном компьютере быстродействие.

python-2.7.2-alt4:
15.02user 0.50system 0:15.57elapsed 99%CPU (0avgtext+0avgdata
2379776maxresident)k
0inputs+0outputs (0major+112925minor)pagefaults 0swaps

python-2.7.2-alt5:
15.31user 0.47system 0:15.83elapsed 99%CPU (0avgtext+0avgdata
2375680maxresident)k
0inputs+0outputs (0major+110620minor)pagefaults 0swaps

python 2.7.2 локальный из тарбола:
11.28user 0.51system 0:11.84elapsed 99%CPU (0avgtext+0avgdata
2363392maxresident)k
0inputs+0outputs (0major+111017minor)pagefaults 0swaps

То есть в alt5 по быстродействию наблюдается даже небольшой регресс по
сравнению с alt4. Несколько раз запустил - результат аналогичный. С
работоспособностью новых пакетов на первых взгляд проблем нет.

--
Денис

Re: [devel] Сборка python3 в Сизифе работает медленно

[Vitaly Kuznetsov]

On Thu, 29 Mar 2012 23:19:10 +0400, Denis Kirienko wrote:
> То есть в alt5 по быстродействию наблюдается даже небольшой регресс 
> по
> сравнению с alt4. Несколько раз запустил - результат аналогичный. С
> работоспособностью новых пакетов на первых взгляд проблем нет.

Попробуйте ещё раз (C) из того же задания, пожалуйста. Пакет обновился, 
но релиз у него тот же (alt5), можете взять из задания только 
python-base и обновить его, этого должно быть достаточно. В моём тесте 
на i586 ускорение порядка 10%.

Re: [devel] побочные эффекты от расчленения питона

[Dmitry V. Levin]

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

On Fri, Mar 30, 2012 at 08:32:30PM +0400, Vitaly Kuznetsov wrote:
> On Thu, 29 Mar 2012 23:19:10 +0400, Denis Kirienko wrote:
> >То есть в alt5 по быстродействию 
> >наблюдается даже небольшой регресс по
> >сравнению с alt4. Несколько раз запустил - 
> >результат аналогичный. С
> >работоспособностью новых пакетов на 
> >первых взгляд проблем нет.
> 
> Попробуйте ещё раз (C) из того же задания, 
> пожалуйста. Пакет обновился, но релиз у 
> него тот же (alt5), можете взять из задания 
> только python-base и обновить его, этого 
> должно быть достаточно. В моём тесте на 
> i586 ускорение порядка 10%.

А это вообще корректное действие?  У нас много модулей слинковано с
-lpython2.7 (что само по себе правильно), как они теперь будут работать?


-- 
ldv

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

Re: [devel] побочные эффекты от расчленения питона

[Vitaly Kuznetsov]

On Tue, 3 Apr 2012 16:28:12 +0400, Dmitry V. Levin wrote:
> On Fri, Mar 30, 2012 at 08:32:30PM +0400, Vitaly Kuznetsov wrote:
>> On Thu, 29 Mar 2012 23:19:10 +0400, Denis Kirienko wrote:
>> >То есть в alt5 по быстродействию
>> >наблюдается даже небольшой регресс по
>> >сравнению с alt4. Несколько раз запустил -
>> >результат аналогичный. С
>> >работоспособностью новых пакетов на
>> >первых взгляд проблем нет.
>>
>> Попробуйте ещё раз (C) из того же задания,
>> пожалуйста. Пакет обновился, но релиз у
>> него тот же (alt5), можете взять из задания
>> только python-base и обновить его, этого
>> должно быть достаточно. В моём тесте на
>> i586 ускорение порядка 10%.
>
> А это вообще корректное действие?  У нас много модулей слинковано с
> -lpython2.7 (что само по себе правильно), как они теперь будут 
> работать?

Я протестировал данный случай. Грузит libpython и работает. Хотя, 
наверное, могла бы и не грузить.

Re: [devel] побочные эффекты от расчленения питона

[Dmitry V. Levin]

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

On Tue, Apr 03, 2012 at 05:08:23PM +0400, Vitaly Kuznetsov wrote:
> On Tue, 3 Apr 2012 16:28:12 +0400, Dmitry V. Levin wrote:
> >А это вообще корректное действие?  У нас 
> >много модулей слинковано с
> >-lpython2.7 (что само по себе правильно), как 
> >они теперь будут работать?
> 
> Я протестировал данный случай. Грузит 
> libpython и работает. Хотя, наверное, могла бы 
> и не грузить.

Не может не грузить, но может неправильно работать.
Два питона, которые делают вид, будто они одинаковые,
но на самом деле они разные, в одной памяти - это риск.


-- 
ldv

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

Re: [devel] побочные эффекты от расчленения питона

[Dmitry V. Levin]

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

On Tue, Apr 03, 2012 at 05:28:54PM +0400, Dmitry V. Levin wrote:
> On Tue, Apr 03, 2012 at 05:08:23PM +0400, Vitaly Kuznetsov wrote:
> > On Tue, 3 Apr 2012 16:28:12 +0400, Dmitry V. Levin wrote:
> > >А это вообще корректное действие?  У нас 
> > >много модулей слинковано с
> > >-lpython2.7 (что само по себе правильно), как 
> > >они теперь будут работать?
> > 
> > Я протестировал данный случай. Грузит 
> > libpython и работает. Хотя, наверное, могла бы 
> > и не грузить.
> 
> Не может не грузить, но может неправильно работать.
> Два питона, которые делают вид, будто они одинаковые,
> но на самом деле они разные, в одной памяти - это риск.

Мы этот вопрос немного поисследовали, и пришли к тому, что для решения
этой и родственных ей проблем модули питона не надо линковать с -lpython.

А для того, чтобы /usr/lib/rpm/verify-elf не жаловался на undefined
symbols, предоставляемые libpython, надо будет доработать verify-elf,
чтобы он при проверке файлов *.so внутри %python_sitelibdir автоматически
LD_PRELOAD'ил соответствующий libpython.

Аналогичный по сути LD_PRELOAD, наверное, имеет смысл сделать при проверке
файлов *.so внутри %perl_vendorarch.


-- 
ldv

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

Re: [devel] побочные эффекты от расчленения питона

[REAL]

05.04.2012 05:33, Dmitry V. Levin пишет:
> А для того, чтобы /usr/lib/rpm/verify-elf не жаловался на undefined
> symbols, предоставляемые libpython, надо будет доработать verify-elf,
> чтобы он при проверке файлов *.so внутри %python_sitelibdir автоматически
> LD_PRELOAD'ил соответствующий libpython.
>
> Аналогичный по сути LD_PRELOAD, наверное, имеет смысл сделать при проверке
> файлов *.so внутри %perl_vendorarch.

Вдогонку ещё вспомнилось от vsu@:

<<
При ошибках о ненайденных символах при вызове питоновских модулей:

[...]

import ctypes
import sys
sys.setdlopenflags(sys.getdlopenflags() | ctypes.RTLD_GLOBAL)
 >>

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

-- 

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

Re: [devel] побочные эффекты от расчленения питона

[Vitaly Kuznetsov]

On Thu, 5 Apr 2012 02:33:28 +0400, Dmitry V. Levin wrote:
>> Не может не грузить, но может неправильно работать.
>> Два питона, которые делают вид, будто они одинаковые,
>> но на самом деле они разные, в одной памяти - это риск.
>
> Мы этот вопрос немного поисследовали, и пришли к тому, что для 
> решения
> этой и родственных ей проблем модули питона не надо линковать с 
> -lpython.
>

Большая часть ныне слинкованных с libpython модулей (что-то около 300 
шт.) потеряет эту зависимость при простой пересборке (остаётся что-то 
около 30 шт.). Я собираюсь массово отправить их на пересборку в 
ближайшее время. Заодно сработает оптимизация зависимостей на 
python-base/python-modules.

Re: [devel] побочные эффекты от расчленения питона

[REAL]

05.04.2012 12:17, Vitaly Kuznetsov пишет:
> Большая часть ныне слинкованных с libpython модулей (что-то около 300
> шт.) потеряет эту зависимость при простой пересборке (остаётся что-то
> около 30 шт.). Я собираюсь массово отправить их на пересборку в
> ближайшее время. Заодно сработает оптимизация зависимостей на
> python-base/python-modules.

Коллеги, а это вы наворотили с макросом %packagename?

<<
http://git.altlinux.org/tasks/68615/logs/events.1.1.log
[...]
arepo/x86_64-i586/rpms/i586-python-module-krb5user-0.1.2-alt2.3.i586.rpm: 
package NAME should start with the "python-module-" prefix
sisyphus_check: check-python ERROR: python modules packaging violation
 >>

<<
http://git.altlinux.org/tasks/68622/logs/events.1.1.log
[...]
arepo/x86_64-i586/rpms/i586-python-module-IceSSL-0.0.5-alt3.1.3.3.i586.rpm: 
package NAME should start with the "python-module-" prefix
sisyphus_check: check-python ERROR: python modules packaging violation
 >>

-- 

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

Re: [devel] побочные эффекты от расчленения питона

[Aleksey Novodvorsky]

5 апреля 2012 г. 9:17 пользователь Vitaly Kuznetsov <vitty@altlinux.ru> написал:
> On Thu, 5 Apr 2012 02:33:28 +0400, Dmitry V. Levin wrote:
>>>
>>> Не может не грузить, но может неправильно работать.
>>> Два питона, которые делают вид, будто они одинаковые,
>>> но на самом деле они разные, в одной памяти - это риск.
>>
>>
>> Мы этот вопрос немного поисследовали, и пришли к тому, что для решения
>> этой и родственных ей проблем модули питона не надо линковать с -lpython.
>>
>
> Большая часть ныне слинкованных с libpython модулей (что-то около 300 шт.)
> потеряет эту зависимость при простой пересборке (остаётся что-то около 30
> шт.). Я собираюсь массово отправить их на пересборку в ближайшее время.
> Заодно сработает оптимизация зависимостей на python-base/python-modules.

Это относится только к Сизифу или к 6 платформе тоже?

Rgrds, Алексей

Re: [devel] побочные эффекты от расчленения питона

[Ivan A. Melnikov]

On Thu, 5 Apr 2012 02:33:28 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:
> 
> Мы этот вопрос немного поисследовали, и пришли к тому, что для решения
> этой и родственных ей проблем модули питона не надо линковать с
> -lpython.
> 
> А для того, чтобы /usr/lib/rpm/verify-elf не жаловался на undefined
> symbols, предоставляемые libpython, надо будет доработать verify-elf,
> чтобы он при проверке файлов *.so внутри %python_sitelibdir
> автоматически LD_PRELOAD'ил соответствующий libpython.
> 
> Аналогичный по сути LD_PRELOAD, наверное, имеет смысл сделать при
> проверке файлов *.so внутри %perl_vendorarch.
> 
> 

А как поступить с libboost_python? Она лежит в %_libdir, но является по
сути вспомогательной для питоновских модулей, то есть загружается
вместе с ними. Апстрим её с -lpython не линкует, я пропатчил сборку,
чтобы линковалась. Возвращать verify_elf relaxed?

-- 
WBR,
Ivan A. Melnikov

Re: [devel] побочные эффекты от расчленения питона

[Vitaly Kuznetsov]

On Thu, 5 Apr 2012 09:27:30 +0400, Aleksey Novodvorsky wrote:
> 5 апреля 2012 г. 9:17 пользователь Vitaly Kuznetsov
> <vitty@altlinux.ru> написал:
>> On Thu, 5 Apr 2012 02:33:28 +0400, Dmitry V. Levin wrote:
>>>>
>>>> Не может не грузить, но может неправильно работать.
>>>> Два питона, которые делают вид, будто они одинаковые,
>>>> но на самом деле они разные, в одной памяти - это риск.
>>>
>>>
>>> Мы этот вопрос немного поисследовали, и пришли к тому, что для 
>>> решения
>>> этой и родственных ей проблем модули питона не надо линковать с 
>>> -lpython.
>>>
>>
>> Большая часть ныне слинкованных с libpython модулей (что-то около 
>> 300 шт.)
>> потеряет эту зависимость при простой пересборке (остаётся что-то 
>> около 30
>> шт.). Я собираюсь массово отправить их на пересборку в ближайшее 
>> время.
>> Заодно сработает оптимизация зависимостей на 
>> python-base/python-modules.
>
> Это относится только к Сизифу или к 6 платформе тоже?
>

Только к Сизифу.

Re: [devel] побочные эффекты от расчленения питона

[Vitaly Kuznetsov]

On Thu, 05 Apr 2012 12:25:32 +0700, REAL wrote:
>
> Коллеги, а это вы наворотили с макросом %packagename?
>
> 
> arepo/x86_64-i586/rpms/i586-python-module-krb5user-0.1.2-alt2.3.i586.rpm:
> package NAME should start with the "python-module-" prefix
> sisyphus_check: check-python ERROR: python modules packaging 
> violation

Это новый arepo, sisyphus_check не пропускает пакеты с префиксом. Надо 
исправлять sisyphus_check.

Re: [devel] побочные эффекты от расчленения питона

[Dmitry V. Levin]

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

On Thu, Apr 05, 2012 at 09:37:00AM +0400, Ivan A. Melnikov wrote:
> On Thu, 5 Apr 2012 02:33:28 +0400, Dmitry V. Levin wrote:
> > 
> > Мы этот вопрос немного поисследовали, и пришли к тому, что для решения
> > этой и родственных ей проблем модули питона не надо линковать с
> > -lpython.
> > 
> > А для того, чтобы /usr/lib/rpm/verify-elf не жаловался на undefined
> > symbols, предоставляемые libpython, надо будет доработать verify-elf,
> > чтобы он при проверке файлов *.so внутри %python_sitelibdir
> > автоматически LD_PRELOAD'ил соответствующий libpython.
> > 
> > Аналогичный по сути LD_PRELOAD, наверное, имеет смысл сделать при
> > проверке файлов *.so внутри %perl_vendorarch.
> 
> А как поступить с libboost_python? Она лежит в %_libdir, но является по
> сути вспомогательной для питоновских модулей, то есть загружается
> вместе с ними. Апстрим её с -lpython не линкует, я пропатчил сборку,
> чтобы линковалась. Возвращать verify_elf relaxed?

Если с -lboost_python линкуются другие, то другого выхода, кроме как
линковать ее с -lpython, не видно.


-- 
ldv

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

Re: [devel] побочные эффекты от расчленения питона

[Ivan A. Melnikov]

On Thu, 5 Apr 2012 14:59:29 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:
> 
> Если с -lboost_python линкуются другие, то другого выхода, кроме как
> линковать ее с -lpython, не видно.
> 

С -lboost_python линкуются в основном модули питона. Получается, при
загрузке такого модуля она "притащет" за собой libpython в адресное
пространство процесса, или я чего-то не понимаю? Получается, в случае
статической сборки питона линковать -lboost_python c -lpython нехорошо.

Я считаю, что нужно вернуться к тому, что делает апстрим, и что
было (и работало) у нас до

* Sun Nov 21 2010 Ivan A. Melnikov <iv@altlinux.org> 1:1.45.0-alt1
[...]
- link libboost_python with libpython;
[...]

Но тогда придётся вернуть в спек строчку

%add_verify_elf_skiplist %_libdir/libboost_python*.so.%version

-- 
WBR,
Ivan A. Melnikov

Re: [devel] побочные эффекты от расчленения питона

[Dmitry V. Levin]

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

On Thu, Apr 05, 2012 at 04:14:18PM +0400, Ivan A. Melnikov wrote:
> On Thu, 5 Apr 2012 14:59:29 +0400, Dmitry V. Levin wrote:
> > 
> > Если с -lboost_python линкуются другие, то другого выхода, кроме как
> > линковать ее с -lpython, не видно.
> > 
> 
> С -lboost_python линкуются в основном модули питона.

В основном, или исключительно модули питона?

Если с библиотекой линкуются executables, то она должна быть долинкована.


-- 
ldv

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

Re: [devel] побочные эффекты от расчленения питона

[Ivan A. Melnikov]

On Thu, 5 Apr 2012 16:52:49 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

> On Thu, Apr 05, 2012 at 04:14:18PM +0400, Ivan A. Melnikov wrote:
> > On Thu, 5 Apr 2012 14:59:29 +0400, Dmitry V. Levin wrote:
> > > 
> > > Если с -lboost_python линкуются другие, то другого выхода, кроме
> > > как линковать ее с -lpython, не видно.
> > > 
> > 
> > С -lboost_python линкуются в основном модули питона.
> 
> В основном, или исключительно модули питона?


Текущие клиенты в сизифе (возможно неточно): vegastrike kdeedu-kig
kde4edu-kig avogadro и 15 модулей питона.

> 
> Если с библиотекой линкуются executables, то она должна быть
> долинкована.
> 

Каковы неприятные последствия недолинковки? Мне library hell,
получающийся от затягивания libpython.so в статически собранный python,
кажется большей проблемой (большим из зол).

-- 
WBR,
Ivan A. Melnikov

Re: [devel] побочные эффекты от расчленения питона

[Dmitry V. Levin]

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

On Thu, Apr 05, 2012 at 05:33:13PM +0400, Ivan A. Melnikov wrote:
> On Thu, 5 Apr 2012 16:52:49 +0400, Dmitry V. Levin wrote:
> > On Thu, Apr 05, 2012 at 04:14:18PM +0400, Ivan A. Melnikov wrote:
> > > On Thu, 5 Apr 2012 14:59:29 +0400, Dmitry V. Levin wrote:
> > > > 
> > > > Если с -lboost_python линкуются другие, то другого выхода, кроме
> > > > как линковать ее с -lpython, не видно.
> > > 
> > > С -lboost_python линкуются в основном модули питона.
> > 
> > В основном, или исключительно модули питона?
> 
> Текущие клиенты в сизифе (возможно неточно): vegastrike kdeedu-kig
> kde4edu-kig avogadro и 15 модулей питона.

Это executables, библиотеки, или модули питона?

> > Если с библиотекой линкуются executables, то она должна быть
> > долинкована.
> 
> Каковы неприятные последствия недолинковки?

Если библиотека недолинкована, то с ней, как правило, не получится
слинковать executable без выключения --as-needed.

> Мне library hell,
> получающийся от затягивания libpython.so в статически собранный python,
> кажется большей проблемой (большим из зол).

Тогда надо вернуть все обратно. :)


-- 
ldv

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

Re: [devel] побочные эффекты от расчленения питона

[Sergey V Turchin]

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

On 5 апреля 2012 18:43:38 Dmitry V. Levin wrote:

[...]
> Если библиотека недолинкована, то с ней, как правило, не получится
> слинковать executable без выключения --as-needed.
--allow-shlib-undefined

[...]

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] побочные эффекты от расчленения питона

[Dmitry V. Levin]

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

On Thu, Apr 05, 2012 at 06:45:12PM +0400, Sergey V Turchin wrote:
> On 5 апреля 2012 18:43:38 Dmitry V. Levin wrote:
> 
> [...]
> > Если библиотека недолинкована, то с ней, как правило, не получится
> > слинковать executable без выключения --as-needed.
> --allow-shlib-undefined

Тогда мы получим настоящий library hell.


-- 
ldv

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

Re: [devel] побочные эффекты от расчленения питона

[Sergey V Turchin]

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

On 5 апреля 2012 18:51:01 Dmitry V. Levin wrote:

[...]
> > > Если библиотека недолинкована, то с ней, как правило, не получится
> > > слинковать executable без выключения --as-needed.
> > 
> > --allow-shlib-undefined
> 
> Тогда мы получим настоящий library hell.
Возможно, но KDE3 все то время я так и собирал ;-)

-- 
Regards, Sergey.       ALT Linux, http://www.altlinux.ru/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] побочные эффекты от расчленения питона

[Ivan A. Melnikov]

On Thu, 5 Apr 2012 18:43:38 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

> On Thu, Apr 05, 2012 at 05:33:13PM +0400, Ivan A. Melnikov wrote:
[...]
> > Текущие клиенты в сизифе (возможно неточно): vegastrike kdeedu-kig
> > kde4edu-kig avogadro и 15 модулей питона.
> 
> Это executables, библиотеки, или модули питона?

Там есть executables, но. (см. ниже)

> 
> > > Если с библиотекой линкуются executables, то она должна быть
> > > долинкована.
> > 
> > Каковы неприятные последствия недолинковки?
> 
> Если библиотека недолинкована, то с ней, как правило, не получится
> слинковать executable без выключения --as-needed.
> 

Любые самостоятельные executables, использующие libboost_python, by
design вынуждены использовать libpython (например, чтобы запустить
интерпретатор -- Boost.Python такого функционала не предоставляет).
Поэтому --as-needed проблем вызвать не должен.

> > Мне library hell,
> > получающийся от затягивания libpython.so в статически собранный
> > python, кажется большей проблемой (большим из зол).
> 
> Тогда надо вернуть все обратно. :)
> 

Так и поступлю. Остался только вопрос, как лучше обойти verify_elf:
будет ли специальная ручка для python? Есть ли тонкая настройка, или
надо, как и раньше, воспользоваться 

%add_verify_elf_skiplist %_libdir/libboost_python*.so.%version

или

%set_verify_elf_method strict unresolved=relaxed

лучше?

-- 
WBR,
Ivan A. Melnikov

Re: [devel] побочные эффекты от расчленения питона

[Dmitry V. Levin]

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

On Thu, Apr 05, 2012 at 08:55:19PM +0400, Ivan A. Melnikov wrote:
> On Thu, 5 Apr 2012 18:43:38 +0400, Dmitry V. Levin wrote:
> 
> > On Thu, Apr 05, 2012 at 05:33:13PM +0400, Ivan A. Melnikov wrote:
> [...]
> > > Текущие клиенты в сизифе (возможно неточно): vegastrike kdeedu-kig
> > > kde4edu-kig avogadro и 15 модулей питона.
> > 
> > Это executables, библиотеки, или модули питона?
> 
> Там есть executables, но. (см. ниже)
> 
> > > > Если с библиотекой линкуются executables, то она должна быть
> > > > долинкована.
> > > 
> > > Каковы неприятные последствия недолинковки?
> > 
> > Если библиотека недолинкована, то с ней, как правило, не получится
> > слинковать executable без выключения --as-needed.
> 
> Любые самостоятельные executables, использующие libboost_python, by
> design вынуждены использовать libpython (например, чтобы запустить
> интерпретатор -- Boost.Python такого функционала не предоставляет).
> Поэтому --as-needed проблем вызвать не должен.

У вашего пакета не останется зависимости на libpython вообще, не говоря
уже о set-versions.  Это тот уровень контроля за совместимостью, который
не хотелось бы терять.

> > > Мне library hell,
> > > получающийся от затягивания libpython.so в статически собранный
> > > python, кажется большей проблемой (большим из зол).
> > 
> > Тогда надо вернуть все обратно. :)
> 
> Так и поступлю.

Я имел в виду изменение в python, последствие которого мы обсуждаем.
Оно мне не нравится все больше и больше.

> Остался только вопрос, как лучше обойти verify_elf:
> будет ли специальная ручка для python? Есть ли тонкая настройка, или
> надо, как и раньше, воспользоваться 
> 
> %add_verify_elf_skiplist %_libdir/libboost_python*.so.%version
> 
> или
> 
> %set_verify_elf_method strict unresolved=relaxed
> 
> лучше?

И так плохо, и сяк нехорошо.  Если говорить о хаках, то для этого пакета,
наверное, лучше подойдет
export LD_PRELOAD=%_libdir/libpython%__python_version.so
в конце секции %install.

Вообще, нам нужны ручки для более тонкой настройки проверок.


-- 
ldv

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

Re: [devel] побочные эффекты от расчленения питона

[Ivan A. Melnikov]

On Thu, 5 Apr 2012 22:25:58 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:
[...]
> 
> У вашего пакета не останется зависимости на libpython вообще, не
> говоря уже о set-versions.  Это тот уровень контроля за
> совместимостью, который не хотелось бы терять.
> 

Это же справедливо и для модулей питона, раз их теперь не линкуют с
libpython.

Если питон собирается статически, то, зависимость libboost_python от
libpython столь же неоправдана, как и зависимость любого модуля.

Идея о set-version provides для /usr/bin/python2.7 кажется абсолютным
безумием.

[...]
> > Остался только вопрос, как лучше обойти verify_elf:
> > будет ли специальная ручка для python? Есть ли тонкая настройка, или
> > надо, как и раньше, воспользоваться 
> > 
> > %add_verify_elf_skiplist %_libdir/libboost_python*.so.%version
> > 
> > или
> > 
> > %set_verify_elf_method strict unresolved=relaxed
> > 
> > лучше?
> 
> И так плохо, и сяк нехорошо.  Если говорить о хаках, то для этого
> пакета, наверное, лучше подойдет
> export LD_PRELOAD=%_libdir/libpython%__python_version.so
> в конце секции %install.
[...]

Честно говря, я шокирован тем, что так можно. Но это действительно
лучший с точки зрения результата хак для данной задачи. Спасибо.

-- 
WBR,
Ivan A. Melnikov

Re: [devel] побочные эффекты от расчленения питона

[REAL]

05.04.2012 19:52, Dmitry V. Levin пишет:
>> С -lboost_python линкуются в основном модули питона.
>
> В основном, или исключительно модули питона?

Нет, не исключительно.

-- 

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

Re: [devel] побочные эффекты от расчленения питона

[Vitaly Kuznetsov]

On Thu, 5 Apr 2012 23:53:37 +0400, Ivan A. Melnikov wrote:
> On Thu, 5 Apr 2012 22:25:58 +0400
> "Dmitry V. Levin" <ldv@altlinux.org> wrote:
> [...]
>>
>> У вашего пакета не останется зависимости на libpython вообще, не
>> говоря уже о set-versions.  Это тот уровень контроля за
>> совместимостью, который не хотелось бы терять.
>>
>
> Это же справедливо и для модулей питона, раз их теперь не линкуют с
> libpython.
>
> Если питон собирается статически, то, зависимость libboost_python от
> libpython столь же неоправдана, как и зависимость любого модуля.
>
> Идея о set-version provides для /usr/bin/python2.7 кажется абсолютным
> безумием.
>
> [...]
>> > Остался только вопрос, как лучше обойти verify_elf:
>> > будет ли специальная ручка для python? Есть ли тонкая настройка, 
>> или
>> > надо, как и раньше, воспользоваться
>> >
>> > %add_verify_elf_skiplist %_libdir/libboost_python*.so.%version
>> >
>> > или
>> >
>> > %set_verify_elf_method strict unresolved=relaxed
>> >
>> > лучше?
>>
>> И так плохо, и сяк нехорошо.  Если говорить о хаках, то для этого
>> пакета, наверное, лучше подойдет
>> export LD_PRELOAD=%_libdir/libpython%__python_version.so
>> в конце секции %install.
> [...]
>
> Честно говря, я шокирован тем, что так можно. Но это действительно
> лучший с точки зрения результата хак для данной задачи. Спасибо.

BTW в Debian с libpython не линкуют, но собирают libboost_python для 
всех имеющихся питонов, т.е. у них получается что-то типа:
libboost_python-py26.so.1.49.0
libboost_python-py27.so.1.49.0
libboost_python-py32.so.1.49.0