+++ Данная ошибка создана размножением ошибки 39329 +++ Начиная с python3 3.9.4-alt1, сборка происходит с прибитым гвоздиком -O2 вместо указанного в %optflags и соответствующего %_optlevel, что само по себе нехорошо (считаю, что bug 39329 была изложена странно). Также наш специалист по оптимизации Илья Курдюков предлагает на x86 и, возможно, других архитектурах задействовать --enable-optimizations=yes, а вот на %e2k делать --with-computed-gotos=no (потребуется обсуждаемая отдельно доработка компилятора и, возможно, кода интерпретатора, чтоб они стали ускорять, а не тормозить); в любом случае по состоянию на сегодня для lcc 1.25 в альте штатным уровнем оптимизации является именно -O3 и разница производительности на всём этом выходит в разы. PS: -O3 гвоздиком же прибил vitty@ в 3.2.2-alt4: http://git.altlinux.org/gears/p/python3.git?p=python3.git;a=commitdiff;h=ab72acf07643aa6b3985631f8a9c3d49854d8335 -- что, впрочем, соответствует нынешнему апстримному configure.ac: http://github.com/python/cpython/blob/main/configure.ac#LC1564
Created attachment 9447 [details] fannkuch.py Прилагаю тест для проверки производительности из Benchmarks Game. Собрано без hasher на x86_64: ./configure --with-computed-gotos=yes --enable-optimizations=no $ time -p python3/python fannkuch.py 11 556355 Pfannkuchen(11) = 51 real 15.60 user 228.23 sys 0.10 $ time -p python3/python fannkuch.py 11 556355 Pfannkuchen(11) = 51 real 16.04 user 233.96 sys 0.17 ./configure --with-computed-gotos=yes --enable-optimizations=yes $ time -p python3/python fannkuch.py 11 556355 Pfannkuchen(11) = 51 real 14.25 user 206.53 sys 0.14 $ time -p python3/python fannkuch.py 11 556355 Pfannkuchen(11) = 51 real 14.13 user 204.83 sys 0.17 Видим +10% к производительности профилирования. На Эльбрусе в разы быстрее с отключением computed-gotos (проблема компилятора): ./configure --with-computed-gotos=yes $ time -p python3/python fannkuch.py 9 8629 Pfannkuchen(9) = 30 real 3.65 user 25.89 sys 0.11 ./configure --with-computed-gotos=no $ time -p python3/python fannkuch.py 9 8629 Pfannkuchen(9) = 30 real 1.08 user 5.58 sys 0.10 --enable-optimizations=yes на Эльбрусе пока невозможно, нужно делать какие-то хаки для компилятора, потому что сбор профиля падает с ошибкой.
И еще нашел две проблемы: 1) --with-valgrind никогда не срабатывает: %if 0%{?with_valgrind} --with-valgrind \ %endif Потому что должно быть {?_with_valgrind} (с почерком), а лучше заменить на %{subst_with valgrind} 2) Должно собираться shared и static, но на самом деле оба раза собирается shared? build() { #see ALT39329 %remove_optflags -g -O3 %configure \ --with-platlibdir=%{_lib} \ --enable-ipv6 \ --enable-shared \ ... pushd ../build-shared build --enable-shared popd
(Ответ для ilyakurdyukov на комментарий #2) > И еще нашел две проблемы: Новые проблемы, не связанные с темой бага, лучше вешать новыми багами, чтобы каждый баг имел чёткий критерий, по которому он (не) решён. За тест спасибо :-)
Да, по поводу valgrind и shared хотел разобраться, но руки не дошли. Спасибо. Оформите отдельные баги, если не сложно, как указал mike@ чуть выше. Касательно обсуждения оптимизации, мне бы хотелось услышать мнение lav@ и ещё кого-нибудь. Насколько я понимаю, либо багу не увидели, либо ваши идеи мало кого интересуют.
(Ответ для Grigory Ustinov на комментарий #4) ... > Касательно обсуждения оптимизации, мне бы хотелось услышать мнение lav@ и > ещё кого-нибудь. Насколько я понимаю, либо багу не увидели, либо ваши идеи > мало кого интересуют. Возможно, в изменения по bug 39329 вкралась ошибка, и действительно в сборке участвует -O2 вне зависимости от указанного в %optflags. Мы на gcc это можем не замечать, а вот на Эльбрусе заметили, потому что у них -O3 в %optflags. Если получится убрать прибитый -O2 в пользу %optflags, было бы здорово.
valgrind и дублированную shared сборку исправили, теперь что с этой опцией ставящей -O2? Во первых и сама сборка проекта ставит -O3, и даже -O3 был явно задан в пакете: > PS: -O3 гвоздиком же прибил vitty@ в 3.2.2-alt4: Что игнорируется патчем. Я считаю что патч нужно откатить совсем, а не гнаться за непонятной красотой в логах. Мало того, этот патч еще отключал отладочную информацию (-g). Что я могу сам сделать, вместе с включением --enable-optimizations, и доработками для Эльбруса.
Я не понимаю, что от меня хотят. На нормальной архитектуре разница между O2 и O3 не заметна. То есть мне бы хотелось понимать, что нужно сделать: а. откатить все изменения по поводу флагов полностью б. оставить как есть в. сделать что-то промежуточное
Предлагаю удалить эти строки из спека: 189 # remove -g and replace -O3 by -O2 in configure.ac 190 # see ALT39329 191 Patch1014: python3-fix-optflags.patch ... 387 %patch1014 -p2 ... 414 #see ALT39329 415 %remove_optflags -g -O3 И, соответственно, файл "python3-fix-optflags.patch". Могу сам это сделать, если вы со мной согласны, что от этого патча как минимум реальной пользы нет (а некоторым и вредит). P.S.: Тем не менее, хотя вы утверждаете что разницы между -O2 и -O3 большинстве архитектур нет, заметил что в libjpeg-turbo, например, тоже ставится -O3 после CFLAGS от пользователя или приходящих по умолчанию от cmake.
Принято.
Изменения на ревью: http://git.altlinux.org/people/ilyakurdyukov/packages/python3.git А мне еще проверить надо, что в новой версии всё работает (завершу уже завтра).
Во-первых, +%ifarch %e2k +# times faster without it on e2k +%global with_computed_gotos no +%else %global with_computed_gotos yes +%endif можно было бы заменить на +%ifnarch %e2k %global with_computed_gotos yes +%endif Так проще и красивее. Во-вторых, чем вам не угодил Patch1013? Он в разы легче для восприятия, чем непонятная абракодабра в сед-выражении. Не говоря уже о том, что если что-то изменится, то патч свалится и его можно будет поймать, а сед просто пропустит мимо. Если это попытка показать ваше умение пользоваться регулярными выражениями, то "принято", а так, подобная вереница регулярок автоматически подписывает вас на решение любых проблем с питоном на эльбрусе. 3. Коммит 0b89b03 можно было бы просто сделать через git revert 4. Коммит 61fc581 было бы неплохо разделить на несколько. Как минимум на 2. Вот в одном мы заменяем патч сед выражением, а в другом творим адскую, практически никак не прокомментированную дичь. Понимаю, что для вас оно очевидно, а для других людей не очень. Так что хотелось бы увидеть хотя бы в описании коммита какие-нибудь комментарии по поводу того, что там происходит и зачем. 5. Ну и наконец, у нас существует система автозакрытия багов. Можно написать в ченджлоге (Closes: #40278) и этот баг закроется после того, как таск закоммитится.
Created attachment 9459 [details] python3.8.1-e2k-plus10.patch
Created attachment 9460 [details] python3.9.5-e2k-plus10.patch Как это... +%ifnarch %e2k %global with_computed_gotos yes +%endif Может работать с этим? --with-computed-gotos=%with_computed_gotos \ Чтобы подавалось "--with-computed-gotos=", что это будет значить? > Во-вторых, чем вам не угодил Patch1013? Он в разы легче для восприятия, чем непонятная абракодабра в сед-выражении. То что заменяет этот патч - понятно. Остальное непонятное - сделано так по той причине, что мелкие правки от разработчиков питона будут часто ломать патч, а такие sed патчи гораздо более устойчивы к изменением. Например, при добавлении или удалении любого нового опкода в интерпретаторе - патч нужно будет обновлять. А связку sed - awk придётся обновлять на порядок реже. Что удобнее и вам и мне, потому что морока и с обновлением, и с тем чтобы добавить патч для Эльбруса в сизиф. Я приложил вам пример патчей, которые бы пришлось постоянно обновлять. sed выражения фактически делают то же самое, только менее красиво, зато автоматически.
(Ответ для ilyakurdyukov на комментарий #13) > То что заменяет этот патч - понятно. Остальное непонятное - сделано так по > той причине, что мелкие правки от разработчиков питона будут часто ломать > патч, а такие sed патчи гораздо более устойчивы к изменением. Например, при > добавлении или удалении любого нового опкода в интерпретаторе - патч нужно > будет обновлять. А связку sed - awk придётся обновлять на порядок реже. Что > удобнее и вам и мне, потому что морока и с обновлением, и с тем чтобы > добавить патч для Эльбруса в сизиф. Еще можно оформить этот набор sed-awk выражений в отдельный скрипт и использовать для генерации нового патча, когда текущий отвалится.
(Ответ для ilyakurdyukov на комментарий #13) > Создано вложение 9460 [details] [подробности] > python3.9.5-e2k-plus10.patch > > Как это... > > +%ifnarch %e2k > %global with_computed_gotos yes > +%endif > > Может работать с этим? Никак. Я погорячился и ошибся. Эта опция по умолчанию yes. Так что, вероятно, сработало бы обратное. > > --with-computed-gotos=%with_computed_gotos \ > > Чтобы подавалось "--with-computed-gotos=", что это будет значить? > > > Во-вторых, чем вам не угодил Patch1013? Он в разы легче для восприятия, чем непонятная абракодабра в сед-выражении. > > То что заменяет этот патч - понятно. Остальное непонятное - сделано так по > той причине, что мелкие правки от разработчиков питона будут часто ломать > патч, а такие sed патчи гораздо более устойчивы к изменением. Например, при > добавлении или удалении любого нового опкода в интерпретаторе - патч нужно > будет обновлять. А связку sed - awk придётся обновлять на порядок реже. Что > удобнее и вам и мне, потому что морока и с обновлением, и с тем чтобы > добавить патч для Эльбруса в сизиф. Хорошо, если вы готовы за этим следить. И всё же было бы неплохо хоть чуть-чуть прокомментировать, что там происходит, на случай если стороннему человеку случайно придётся это поддержать. > > Я приложил вам пример патчей, которые бы пришлось постоянно обновлять. sed > выражения фактически делают то же самое, только менее красиво, зато > автоматически. Холивар "патчи против регулярок" длится уже давно, я не хочу в нём участвовать.
Если хочется сделать красиво, то можно сделать так: %configure \ --with-platlibdir=%{_lib} \ --enable-ipv6 \ --enable-shared \ --enable-optimizations \ %ifarch %e2k --with-computed-gotos=no \ %endif ... Но придётся еще писать комментарий чтобы это никто не сломал. Потому что, стороннему наблюдателю обязательно покажется, что так: %ifnarch %e2k --with-computed-gotos \ %endif ...было бы логичнее и красивее, и исправит не зная как эта опция работает. --with-computed-gotos enable computed gotos in evaluation loop (enabled by default on supported compilers) То есть включается она по умолчанию для тех компиляторов, которые смогли скомпилировать тест с этой фичей. Значит считается что фича поддерживается и даст ускорение. Фича называется Labels as Values, которая не является стандартом, а расширение GNU компиляторов. https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html Проблема компилятора для Эльбруса, что она работает, но работает очень медленно. Чтобы её сделать быстрой - говорят что нужны сложные изменения в компиляторе. Фича же используется крайне редко, это второй раз как я вижу её использование. Первый раз видел в OpenJDK Zero, это интерпретатор Java. Соответственно, оптимизацию редкой фичи откладывают. Поэтому этот sed - awk патч подводит компилятор к тому, чтобы он сгенерировал правильный код не используя Labels as Values, но используя обычный switch. Для этого требуется указать что default: метка в switch никогда не вызывается (unreachable), и тогда компилятор уберёт проверки диапазона значений перед прыжком по таблице меток. #if USE_COMPUTED_GOTOS _unknown_opcode: #endif default: fprintf(stderr, "XXX lineno: %d, opcode: %d\n", PyFrame_GetLineNumber(f), opcode); _PyErr_SetString(tstate, PyExc_SystemError, "unknown opcode"); goto error; Но это вызывает неопределённое поведение, если когда-либо попадутся опкоды, не указанные в case-ах switch. Возможные же значения опкодов находятся в пределах байта. Поэтому нужно найти все номера кейсов в диапазоне 0-255, котоыре НЕ были использованы. Что могло бы быть сложной задачей, но к счастью, для использования Labels as Values вручную создаётся таблица прыжков, которая находится в файле opcode_targets.h, и выглядит так: static void *opcode_targets[256] = { &&_unknown_opcode, <--- case 0 &&TARGET_POP_TOP, <--- case 1 &&TARGET_ROT_TWO, <--- case 2 &&TARGET_ROT_THREE, <--- case 3 &&TARGET_DUP_TOP, <--- case 4 &&TARGET_DUP_TOP_TWO, <--- case 5 &&TARGET_ROT_FOUR, <--- case 6 &&_unknown_opcode, <--- case 7 &&_unknown_opcode, &&TARGET_NOP, &&TARGET_UNARY_POSITIVE, &&TARGET_UNARY_NEGATIVE, ... &&_unknown_opcode, &&_unknown_opcode, &&_unknown_opcode, <--- case 254 &&_unknown_opcode <--- case 255 }; Что позволяет сгенерировать эти кейсы простым awk скриптом: awk '/_unknown_opcode/{print "case " NR-2 ":"}' Python/opcode_targets.h > Python/opcode_unknown.h Как мы видим, первый _unknown_opcode соответствует первой позиции в таблице, что находится на второй строке. Для него скрипт выдаст: "case 0:\n", cледующим будет "case 7:\n". Если первый опкод окажется не на второй строке или стройный порядок перечисления опкодов изменится, то произойдёт ошибка при компиляции, так как unknown кейсы совпадут с номерами существующих. А далее лишь нужно вставить этот список после default: в switch интерпретатора, что делает этот код: sed -i "/_unknown_opcode:/{n;n;s|$|Py_UNREACHABLE();\n#include \"opcode_unknown.h\"|}" Python/ceval.c Py_UNREACHABLE() это обёртка над __builtin_unreachable(). Поиск нужного места ведётся по "_unknown_opcode:" что встречается за две строки перед нужным "default:", так как default встречается в исходнике четыре раза, а _unknown_opcode упоминается лишь один раз. Это нужно чтобы найти начало switch интерпретатора и добавить себе метку для прыжка на него: sed -i "/switch (opcode) {/{s|^|switch_loop:|;:a;n;ba}" Python/ceval.c Эта замена: sed -i "s|\\*opcode_targets\\[opcode\\]|switch_loop|" Python/ceval.c Далее нужно сделать из макросов, использующих Labels as Values, макросы делающие практически то же самое, но с прыжком на начало switch, вместо таблицы меток: #if USE_COMPUTED_GOTOS /* Import the static jump table */ #include "opcode_targets.h" #define TARGET(op) \ op: \ TARGET_##op #ifdef LLTRACE #define FAST_DISPATCH() \ { \ if (!lltrace && !_Py_TracingPossible(ceval2) && !PyDTrace_LINE_ENABLED()) { \ f->f_lasti = INSTR_OFFSET(); \ NEXTOPARG(); \ goto *opcode_targets[opcode]; \ } \ goto fast_next_opcode; \ } #else #define FAST_DISPATCH() \ { \ if (!_Py_TracingPossible(ceval2) && !PyDTrace_LINE_ENABLED()) { \ f->f_lasti = INSTR_OFFSET(); \ NEXTOPARG(); \ goto *opcode_targets[opcode]; \ } \ goto fast_next_opcode; \ } #endif #define DISPATCH() \ { \ if (!_Py_atomic_load_relaxed(eval_breaker)) { \ FAST_DISPATCH(); \ } \ continue; \ } #else #define TARGET(op) op #define FAST_DISPATCH() goto fast_next_opcode #define DISPATCH() continue #endif В коде выше нужно принудительно пойти по пути #if USE_COMPUTED_GOTOS, так как нам нужно позаимствовать оттуда определения макросов FAST_DISPATCH и DISPATCH. Но нужно удалить инклуд "opcode_targets.h", заменить макрос "TARGET(op) op: TARGET_##op", на простой "TARGET(op) op" и заменить "goto *opcode_targets[opcode];" на "goto switch_loop;" (switch_loop который ставится перед switch интерпретатора другим sed вызовом). Удаление opcode_targets.h и старого TARGET(op) делается пропуском от первого #if USE_COMPUTED_GOTOS, до того как будет найдено упоминание LLTRACE. #if USE_COMPUTED_GOTOS встречается в исходнике не один раз, поэтому после нахождения и изменения первого #if USE_COMPUTED_GOTOS - sed скрипт далее пропускает все строки, ничего не делая. Всё это делается этим вызовом sed: sed -i "/#if USE_COMPUTED_GOTOS/{:b;g;N;/LLTRACE/!bb;s|^|#undef USE_COMPUTED_GOTOS\n#define USE_COMPUTED_GOTOS 0\n#if 1\n#define TARGET(op) op|;:a;n;ba}" Python/ceval.c Да, еще USE_COMPUTED_GOTOS присваивается 0, так что по идее с этим патчем "--with-computed-gotos=no" больше не нужно, но лучше передавать всё равно, на случай если кто-то захочет проверить разницу вносимую sed - awk пачтем, сейчас это +10% к производительности. Вы думаете, что всё это должно быть написано в комментариях в спеке? Для любопытных я могу оставить номер бага. P.S.: Это притом, что чтобы это понять нужно еще и знать почему Labels as Values (если грамотно реализовано) быстрее обычного switch. Для чего вероятно, нужно знать в какой ассемблер компилятор превращает то и другое.
TL;DR версия: Обычно switch превращается компилятором в такую конструкцию: if (x < first_case | x > last_case) goto default; goto *labels[x - first_case]; sed - awk патч убирает первую строку с проверкой диапазона. Сохраняя при этом обработку default: для неизвестных значений опкодов в пределах 0-255, а больше никакие другие значения прийти не могут. Сделано это без использования фичи Labels as Values, медленной в исполнении компилятора для Эльбруса. --with-computed-gotos - делает именно это, но с использованием Labels as Values.
> Вы думаете, что всё это должно быть написано в комментариях в спеке? Для любопытных я могу оставить номер бага. Да, пожалуй. Выглядит оно мощно!
Обновил: http://git.altlinux.org/people/ilyakurdyukov/packages/python3.git > можно было бы просто сделать через git revert git revert не справился, потому что рядом были изменения. Так что сделал вручную, благо правки небольшие.
(Ответ для ilyakurdyukov на комментарий #16) > Если хочется сделать красиво, то можно сделать так: > > %configure \ > --with-platlibdir=%{_lib} \ > --enable-ipv6 \ > --enable-shared \ > --enable-optimizations \ > %ifarch %e2k > --with-computed-gotos=no \ > %endif > ... > > Но придётся еще писать комментарий чтобы это никто не сломал. > Потому что, стороннему наблюдателю обязательно покажется, что так: > > %ifnarch %e2k > --with-computed-gotos \ > %endif > > ...было бы логичнее и красивее, и исправит не зная как эта опция работает. > > --with-computed-gotos enable computed gotos in evaluation loop (enabled > by > default on supported compilers) > > То есть включается она по умолчанию для тех компиляторов, которые смогли > скомпилировать тест с этой фичей. Значит считается что фича поддерживается и > даст ускорение. Фича называется Labels as Values, которая не является > стандартом, а расширение GNU компиляторов. > > https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html > > Проблема компилятора для Эльбруса, что она работает, но работает очень > медленно. Чтобы её сделать быстрой - говорят что нужны сложные изменения в А не правильнее было бы сделать так, чтобы компилятор Эльбруса перестал быть supported compiler для этой фичи?
Таки почему-то локальная static x86_64 сборка предыдущей версии у меня выходит заметно быстрее сборки из hasher: $ LD_LIBRARY_PATH=$TMP/chroot/usr/src/tmp/python3-buildroot/usr/lib64/ time -p $TMP/chroot/usr/src/tmp/python3-buildroot/usr/bin/python3 fannkuch.py 11 4 556355 Pfannkuchen(11) = 51 real 33.31 user 130.37 sys 0.05 $ time -p python3/python fannkuch.py 11 4 556355 Pfannkuchen(11) = 51 real 27.85 user 108.16 sys 0.05 Может shared сборка медленнее чем static? Или из-за каких-то флагов? > А не правильнее было бы сделать так, чтобы компилятор Эльбруса > перестал быть supported compiler для этой фичи? Там нет списка поддерживаемых компиляторов, просто проверяют что следующий код скомпилируется: int main(int argc, char **argv) { static void *targets[1] = { &&LABEL1 }; goto LABEL2; LABEL1: return 0; LABEL2: goto *targets[0]; return 1; } Если скомпилировался - значит поддерживается. Но LCC всё равно притворяется GCC 7.3.0 так что и список бы не помог.
Created attachment 9464 [details] fannkuch.py Прилагаю новую версию fannkuch.py, которым я тестирую производительность, добавил параметр с количеством потоков, так как он использовал по количеству процессоров, что даёт больше погрешности. Я выяснил что вот этот патч ломает static билд: # 00111 # # Patch the Makefile.pre.in so that the generated Makefile doesn't try to build # a libpythonMAJOR.MINOR.a # See https://bugzilla.redhat.com/show_bug.cgi?id=556092 # Downstream only: not appropriate for upstream Patch111: 00111-no-static-lib.patch Ошибка такая: make[3]: *** No rule to make target 'libpython3.9.a', needed by 'python'. Stop. Зачём это нужно, мне не ясно. Я в оптимизациях разбираюсь, а не в таких тонкостях что статическая библиотека кому-то помешала. > https://bugzilla.redhat.com/show_bug.cgi?id=556092 > We could change things to not build it, or we could simply delete it after linking: I've chosen to patch the Makefile.pre.in to not build it. Мне кажется, что они там ерундой страдают. Гораздо проще удалить файл, чем годами поддерживать этот патч. Который еще и static билд ломает, а значит вредительский. Различия же в производительности static билда очень ощутимые (на 25% быстрее). Почему так происходит - я не знаю. Но я думаю, что ради этого стоит откатить патч из Федоры, его необходимость для меня сомнительна. Возможно патч сломался после каких-то изменений в питоне. # hasher shared (./configure --enable-shared --enable-optimizations --with-valgrind) $ LD_LIBRARY_PATH=$TMP/chroot/usr/src/tmp/python3-buildroot/usr/lib64/ time -p nice $TMP/chroot/usr/src/tmp/python3-buildroot/usr/bin/python3 fannkuch.py 11 4 556355 Pfannkuchen(11) = 51 real 32.81 user 127.51 sys 0.06 # hasher static (./configure --enable-optimizations --with-valgrind) $ LD_LIBRARY_PATH=$TMP/chroot/usr/src/tmp/python3-buildroot/usr/lib64/ time -p nice $TMP/chroot/usr/src/tmp/python3-buildroot/usr/bin/python3 fannkuch.py 11 4 556355 Pfannkuchen(11) = 51 real 26.29 user 102.55 sys 0.06
(Ответ для ilyakurdyukov на комментарий #22) > Мне кажется, что они там ерундой страдают. Гораздо проще удалить файл, чем > годами поддерживать этот патч. Который еще и static билд ломает, а значит > вредительский. Гораздо проще ничего не менять, если никому не мешает=) Золотое правило мастера "не чини то, что работает". > > Различия же в производительности static билда очень ощутимые (на 25% > быстрее). Почему так происходит - я не знаю. Но я думаю, что ради этого > стоит откатить патч из Федоры, его необходимость для меня сомнительна. > Возможно патч сломался после каких-то изменений в питоне. Предлагаю подобные отдельные ветви обсуждений выносить в отдельные баги, чтобы не потерялось и чтобы не путаться в обсуждениях.
Итак, вот коммиты, которыми я вроде бы починил все найденные проблемы с производительностью: http://git.altlinux.org/people/ilyakurdyukov/packages/python3.git Еще у меня есть подозрения что --with-valgrind может негативно влиять, но видимо эта разница небольшая, я проверяю на basalt, которая еще и как шлюз используется и на ней есть небольшая фоновая нагрузка. Но разница между static и shared точно вызвана не флуктуациями загрузки, так как очень значительная. Требуются тестеры для сравнения 3.9.6-alt1 и этого кандидата в 3.9.6-alt2. Можете использовать приложенный к багу fannkuch.py и другие вычислительные тесты, что найдёте.
Посоветовали: https://src.fedoraproject.org/rpms/python3/pull-request/151 > The compiler flag has been added to CFLAGS_NODIST and > LDFLAGS_NODIST. This will compile the core interpreter > and the stdlib modules with -fno-semantic-interposition > but will not affect user build and rpm C extension modules > compiled by distutils. > This has the effect of speeding up the interpreter up to > 27%, depending on the workload, with the drawback of disabling > the capability of using LD_PRELOAD to override symbols in > libpython. > https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup Собирал в убунте, тоже static быстрее, но на 10%. Причём системный питон работает много быстрее - вот у кого спеки смотреть надо. $ time -p python3 fannkuch.py 11 2 shared: 73.56 static: 66.59 system: 56,71
Вчера проверял, но вне hasher: export CFLAGS_NODIST="-fno-semantic-interposition" export LDFLAGS_NODIST="-fno-semantic-interposition" Перед configure - делает shared билд почти таким же быстрым как static. Почти потому, что на 3% у меня вышло медленнее, непонятно, наводка ли это от системных процессов или действительно медленнее. На Эльбрусе же такая опция не поддерживается. Так что, если хотите shared билд - могу сделать для Эльбруса static, для всех остальных с этой опцией.
(In reply to ilyakurdyukov from comment #26) > Вчера проверял, но вне hasher: > > export CFLAGS_NODIST="-fno-semantic-interposition" > export LDFLAGS_NODIST="-fno-semantic-interposition" > > Перед configure - делает shared билд почти таким же быстрым как static. > Почти потому, что на 3% у меня вышло медленнее, непонятно, наводка ли это от > системных процессов или действительно медленнее. > > На Эльбрусе же такая опция не поддерживается. > > Так что, если хотите shared билд - могу сделать для Эльбруса static, для > всех остальных с этой опцией. А разве кто-то специально хочет shared build интерпретатора? Изначально он делался vitty@ static из-за скорости, и по большому счёту к этому у нас пакеты и инфраструктура были подготовлены. С т.зр. тестированности лучше, когда более похожи пакеты на разных платформах. (Т.е. везде static, например.) На x86_64 замедление shared build должно быть не так заметно, как на архитектурах с меньшим количеством регистров (или где их много требуется задействовать для вызовов функций следуя ABI), т.е. например, i586. (Ну, это такие теоретические соображения.) Согласен, что патч, от которого нет особый пользы, и который можно просто заменить rm, лучше не тащить, потому что с ним больше труда для мейнтейнера.
(In reply to Vitaly Lipatov from comment #20) > (Ответ для ilyakurdyukov на комментарий #16) > > Если хочется сделать красиво, то можно сделать так: > > > > %configure \ > > --with-platlibdir=%{_lib} \ > > --enable-ipv6 \ > > --enable-shared \ > > --enable-optimizations \ > > %ifarch %e2k > > --with-computed-gotos=no \ > > %endif > > ... > > > > Но придётся еще писать комментарий чтобы это никто не сломал. > > Потому что, стороннему наблюдателю обязательно покажется, что так: > > > > %ifnarch %e2k > > --with-computed-gotos \ > > %endif > > > > ...было бы логичнее и красивее, и исправит не зная как эта опция работает. > > > > --with-computed-gotos enable computed gotos in evaluation loop (enabled > > by > > default on supported compilers) > > > > То есть включается она по умолчанию для тех компиляторов, которые смогли > > скомпилировать тест с этой фичей. Значит считается что фича поддерживается и > > даст ускорение. Фича называется Labels as Values, которая не является > > стандартом, а расширение GNU компиляторов. > > > > https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html > > > > Проблема компилятора для Эльбруса, что она работает, но работает очень > > медленно. Чтобы её сделать быстрой - говорят что нужны сложные изменения в > А не правильнее было бы сделать так, чтобы компилятор Эльбруса перестал быть > supported compiler для этой фичи? Мне бы такой подход тоже понравился ещё больше. (И послать в upstream, если этот механизм родом из upstream.)
> На x86_64 замедление shared build должно быть не так заметно, как на архитектурах с меньшим количеством регистров +25% разница на вычислениях в питоне как раз на x86_64. А на Эльбрусе с 256 регистрами и еще выше. Насколько я понял, какие-то правила экспортирования символов в библиотеках мешают оптимизациям, и эта опция говорит компилятору что можно делать некоторые оптимизации. А ломает это только на то, что пользователь не сможет делать LD_PRELOAD хаки, когда можно подгрузить свою либу, которая имеет те же имена функций, что имена функций из libpython, и подменяет их. > For a non-vague-linkage function definition, by default (-fsemantic-interposition) the -fpic > mode does not allow a call site in the same translation unit to inline the callee or perform > other interprocedural optimizations. -fno-semantic-interposition re-enables interprocedural > optimizations. > If a caller inlines a callee, using LD_PRELOAD to interpose the callee will not affect the caller. > But many other LD_PRELOAD usage still work. We consider the small LD_PRELOAD limitation a good > trade off for the speedup. > А разве кто-то специально хочет shared build интерпретатора? В Федоре похоже принципиальная позиция, что они всё делают только shared. В Убунту же явно статик. > Мне бы такой подход тоже понравился ещё больше. (И послать в upstream, если этот механизм родом из upstream.) Пока широкой розничной доступности не будет - это проблема. Потому что зарубежному апстриму негде взять железо для проверки патчей.
(In reply to ilyakurdyukov from comment #29) > > На x86_64 замедление shared build должно быть не так заметно, как на архитектурах с меньшим количеством регистров > +25% разница на вычислениях в питоне как раз на x86_64. А на Эльбрусе с 256 > регистрами и еще выше. Насколько я понял, какие-то правила экспортирования > символов в библиотеках мешают оптимизациям, и эта опция говорит компилятору > что можно делать некоторые оптимизации. А ломает это только на то, что > пользователь не сможет делать LD_PRELOAD хаки, когда можно подгрузить свою > либу, которая имеет те же имена функций, что имена функций из libpython, и > подменяет их. > > > For a non-vague-linkage function definition, by default (-fsemantic-interposition) the -fpic > > mode does not allow a call site in the same translation unit to inline the callee or perform > > other interprocedural optimizations. -fno-semantic-interposition re-enables interprocedural > > optimizations. > > If a caller inlines a callee, using LD_PRELOAD to interpose the callee will not affect the caller. > > But many other LD_PRELOAD usage still work. We consider the small LD_PRELOAD limitation a good > > trade off for the speedup. Я имел в виду, что помимо этого обнаруженного на x86_64 фактора вероятно есть другие, которые могут иметь эффект только на i586 и т.п. (Если разница без -fno-semantic-interposition обнаружилась на x86_64 и она "лечится" этой опцией, это не значит, что нет разницы в скорости на i586 независимо от наличия этого флага.)
(In reply to ilyakurdyukov from comment #29) > > Мне бы такой подход тоже понравился ещё больше. (И послать в upstream, если этот механизм родом из upstream.) > Пока широкой розничной доступности не будет - это проблема. Потому что > зарубежному апстриму негде взять железо для проверки патчей. Но патч без кода, а просто делающий выбор опций в зависимости от моедли компилятора могут и принять без тестирования. Есть подобные (и не совсем) патчи ради компиляции на e2k, принятые в другие upstream-ы.
Для понимания что такое -fno-semantic-interposition (я полагаю может пригодиться в других проектах): Эта опция отменяет ограничения на межпроцедурную оптимизацию введенные -fPIC. Например у нас есть код: int mul3(int x) { return x * 3; } int mul9(int x) { return mul3(mul3(x)); } Где компилятор, которому указано -fPIC, не может заинлайнить mul3() в mul9(), а делает два вызова mul3 даже зная что такую простую функцию можно заинлайнить, заменив вызовы на return x * 9; Если же указать -fno-semantic-interposition, то это будет сделано. Соответственно, если mul3 заинлайнен в mul9, то LD_PRELOAD библиотеки которая экспортирует int mul3(int x) { return x * 4; } не заставит mul9() умножать на 16. Попросил МЦСТ чтобы добавили такую опцию.
Хорошо бы не затягивать с исправлением производительности. Чтобы в p10 ушла быстрая версия. Такое уже бывало? На других архитектурах не было ошибки. [armh] 1 test failed: [armh] test_hashlib [armh] 22 tests skipped: [armh] test_curses test_devpoll test_gdb test_ioctl test_kqueue [armh] test_msilib test_nis test_ossaudiodev test_smtpnet [armh] test_socketserver test_startfile test_timeout test_tix test_tk [armh] test_ttk_guionly test_urllib2net test_urllibnet test_winconsoleio [armh] test_winreg test_winsound test_xmlrpc_net test_zipfile64 [armh] Total duration: 2 min 39 sec [armh] Tests result: FAILURE http://git.altlinux.org/tasks/276715/build/100/armh/log [00:43:17] 0:00:02 load avg: 3.79 [137/424/1] test_hashlib crashed (Exit code -7)
(Ответ для ilyakurdyukov на комментарий #33) > Хорошо бы не затягивать с исправлением производительности. Чтобы в p10 ушла > быстрая версия. > > Такое уже бывало? На других архитектурах не было ошибки. Нет, это что-то новенькое.
Отключил PGO для armh, теперь собралось везде. http://git.altlinux.org/tasks/276773/logs/events.1.1.log Падение на том тесте не случайное, повторно воспроизводилось. Видимо компилятор переоптимизировал, возможно баг компилятора.
(In reply to ilyakurdyukov from comment #35) > Отключил PGO для armh, теперь собралось везде. > > http://git.altlinux.org/tasks/276773/logs/events.1.1.log > > Падение на том тесте не случайное, повторно воспроизводилось. Видимо > компилятор переоптимизировал, возможно баг компилятора. Спасибо за всю эту работу! Теперь, когда интерпретатор собран статически, часть пакетов (возможно) ошибочно динамически линкует модули с libpython3.9.so.1.0. (Речь идёт именно о модулях, а не программах, которые используют python как встроенный интерпретатор. Какие в этом списке какие -- предстоит разобраться, чтобы вернуть всё как было раньше, когда интерпретатор в ALT собирался всё ещё статически.) [imz@altair ~]$ cat ~/hasher/aptbox/etc/apt/sources.list rpm-dir file:/tmp/.private/imz/hasher/repo x86_64 hasher rpm [alt] file:/ALT/Sisyphus x86_64 classic debuginfo checkinstall rpm [alt] file:/ALT/Sisyphus noarch classic checkinstall rpm [alt] file:/ALT/Sisyphus x86_64-i586 classic [imz@altair ~]$ ~/hasher/aptbox/apt-cache whatdepends 'libpython3.9.so.1.0()(64bit)' <libpython3.9.so.1.0()(64bit)> weechat-plugin-python-3.0-alt1:sisyphus+274516.36400.2.1@1623665973 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-vtkaddon-0-alt1.git.402e7c6:sisyphus+273287.2200.5.3@1622762129 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-vtk-9.0.1-alt5:sisyphus+275609.100.2.1@1624610186 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libvtk9.0-python3-9.0.1-alt5:sisyphus+275609.100.2.1@1624610186 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libvtk9.0-9.0.1-alt5:sisyphus+275609.100.2.1@1624610186 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-vboxapi-6.1.22-alt1:sisyphus+271870.100.4.2@1621205089 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 vim-enhanced-4:8.2.0011-alt3:sisyphus+274516.3000.1.1@1623613487 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 vim-X11-neXtaw-4:8.2.0011-alt3:sisyphus+274516.3000.1.1@1623613487 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 vim-X11-gtk2-4:8.2.0011-alt3:sisyphus+274516.3000.1.1@1623613487 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 vim-X11-gnome2-4:8.2.0011-alt3:sisyphus+274516.3000.1.1@1623613487 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libvapoursynth-53-alt1:sisyphus+270454.100.1.1@1619068724 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 uwsgi-2.0.18-alt1:sisyphus+265234.21500.49.1@1613754902 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-uhd-3.15.0.0-alt6.1:sisyphus+273092.200.1.1@1622480604 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 syslog-ng-python3-3.32.1-alt1:sisyphus+274086.400.4.1@1623188981 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 sudo-python-1:1.9.7-alt1:sisyphus+271887.100.1.1@1621022852 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 slicer-4.11.20210226-alt1:sisyphus+276144.300.2.1@1624882290 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 scribus-1:1.5.7-alt1.1:sisyphus+274992.100.1.1@1624381968 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-samba-4.14.5-alt1:sisyphus+273560.100.2.1@1624188304 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-qpid-proton-0.28.0-alt1.1:sisyphus+273102.1600.4.1@1622494580 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 qgis3-python-3.18.3-alt1:sisyphus+272347.100.1.1@1621692091 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libpythonqt-0-alt1.git.dafdb72:sisyphus+273287.1700.5.3@1622761569 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-pynest2d-4.8-alt2:sisyphus+265234.42700.49.1@1613771698 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-gst1.0-1.18.4-alt1:sisyphus+267876.600.1.1@1615841302 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-cx-freeze-6.1-alt1:sisyphus+265234.33100.49.1@1613764407 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-caja-1.24.0-alt1:sisyphus+265234.42200.49.1@1613771272 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-shiboken2-5.15.0-alt4:sisyphus+265234.42720.50.1@1613896979 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-PySide2-5.15.0-alt4:sisyphus+265234.42720.50.1@1613896979 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-PyQt5-5.13.1-alt3:sisyphus+265234.43400.50.1@1613897523 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql9.6-python-9.6.22-alt1:sisyphus+274516.11400.1.1@1623618701 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql13-python-13.3-alt1:sisyphus+274516.4500.1.1@1623614512 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql12-1C-python-12.6-alt3:sisyphus+274516.11300.1.1@1623618431 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql12-1C-contrib-12.6-alt3:sisyphus+274516.11300.1.1@1623618431 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql12-python-12.7-alt1:sisyphus+274516.11100.1.1@1623617870 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql12-contrib-12.7-alt1:sisyphus+274516.11100.1.1@1623617870 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql11-python-11.12-alt1:sisyphus+274516.11000.1.1@1623617585 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql11-contrib-11.12-alt1:sisyphus+274516.11000.1.1@1623617585 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql10-python-10.17-alt2:sisyphus+274516.11200.1.1@1623618142 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 postgresql10-contrib-10.17-alt2:sisyphus+274516.11200.1.1@1623618142 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 pitivi-2021.05-alt1:sisyphus+272866.200.2.1@1622409755 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 perl-Inline-Python-0.56-alt1:sisyphus+274516.53400.2.1@1623671172 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-partio-1.14.0-alt1:sisyphus+274474.200.1.1@1623522713 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-libpamtest-1.1.3-alt1.1:sisyphus+269879.17400.53.1@1622285275 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-openshadinglanguage-1.11.14.1-alt1:sisyphus+274117.340.3.2@1623320459 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-openbabel-2.4.1-alt7:sisyphus+265234.27300.49.1@1613759478 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 obs-studio-base-27.0.1-alt2:sisyphus+276040.200.2.1@1624796313 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libobs-27.0.1-alt2:sisyphus+276040.200.2.1@1624796313 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-ngsolve-6.2.2103-alt1:sisyphus+274615.300.2.1@1623829837 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libngsolve-6.2.2103-alt1:sisyphus+274615.300.2.1@1623829837 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-netgen-6.2.2103-alt2:sisyphus+274615.100.1.1@1623772101 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libnetgen-6.2.2103-alt2:sisyphus+274615.100.1.1@1623772101 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 nemo-python-5.0.1-alt1:sisyphus+276160.600.2.1@1624999290 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 nautilus-python-1.2.3-alt2:sisyphus+265234.42600.49.1@1613771651 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 mysql-workbench-community-8.0.25-alt1:sisyphus+272319.1100.10.1@1622580477 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-log4cplus-2.0.6-alt1:sisyphus+274735.100.1.1@1624006201 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 perf-5.13-alt1:sisyphus+276445.300.3.1@1625013959 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-talloc-1:2.3.2-alt1:sisyphus+268191.100.8.1@1616984054 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libsigrokdecode-0.5.3-alt2:sisyphus+265234.30700.49.1@1613761948 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-savitar-4.8-alt1:sisyphus+265234.26500.49.1@1613758671 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libpeas-python3-loader-1.30.0-alt1:sisyphus+268501.3600.4.2@1617047300 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-openshot-0.2.5-alt3.1:sisyphus+271676.1240.3.1@1622401220 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-pyldb-2.3.0-alt1:sisyphus+268191.540.8.1@1616984229 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-libcomps-0.1.17-alt1_1:sisyphus+274849.100.1.1@1624274584 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-cec-6.0.2-alt1:sisyphus+265234.1200.49.1@1613743606 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-ldns-1.7.1-alt1.git.e99accb9:sisyphus+265234.25700.49.1@1613758136 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 krita-4.4.2-alt1:sisyphus+265234.50700.50.1@1613901027 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 kodi-bin-19.1-alt1:sisyphus+274595.100.1.1@1623759880 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 kmymoney-weboob-5.1.2-alt3:sisyphus+276737.100.2.1@1625221305 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 kitty-0.21.2-alt1:sisyphus+276142.100.2.2@1624869903 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 kicad-1:5.1.9-alt2.1:sisyphus+273312.200.3.2@1622570598 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 kde5-kig-21.04.1-alt1:sisyphus+272539.1400.1.1@1622016524 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 kde5-cantor-21.04.1-alt1:sisyphus+272539.1700.1.1@1622016867 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 hugin-2020.0.0-alt1:sisyphus+275077.100.1.2@1624412528 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libges-1.18.4-alt1:sisyphus+267876.1200.1.1@1615841595 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 gnuradio-3.9.1.0-alt1:sisyphus+271536.100.1.1@1620837010 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 gnumeric-1.12.50-alt1:sisyphus+274516.31500.2.1@1623663581 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libgladeui2.0-3.39.0-alt0.1:sisyphus+270761.100.1.1@1619503359 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 gdb-10.1-alt1:sisyphus+265234.500.49.1@1613741942 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 freecad-1:0.19.2-alt2:sisyphus+271619.1700.16.2@1621461369 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libfontforge-20201107-alt1:sisyphus+265234.31600.49.1@1613762820 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 ceph-mgr-15.2.13-alt1:sisyphus+276363.100.1.3@1625001559 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 calibre-4.23.0-alt3:sisyphus+276534.20.4.3@1625176475 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 blender-2.93.1-alt1:sisyphus+276143.100.2.2@1624885452 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 apache2-mod_wsgi-py3-4.8.0-alt1:sisyphus+272442.100.1.1@1621930032 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 adonthell-0.3.6-alt1_9:sisyphus+265234.200.49.1@1613741537 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 LibreOffice-still-common-7.0.6.2-alt2:sisyphus+276330.100.1.3@1624985903 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 LibreOffice-common-7.1.3.2-alt1:sisyphus+274980.100.1.2@1624383308 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 python3-module-CTK-0.1.0-alt1.git.dc2e1289:sisyphus+273287.2000.5.3@1622761894 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 libCTK-0.1.0-alt1.git.dc2e1289:sisyphus+273287.2000.5.3@1622761894 Depends: <libpython3.9.so.1.0()(64bit)> libpython3-3.9.6-alt1:sisyphus+276295.100.1.1@1624964289 [imz@altair ~]$
> Теперь, когда интерпретатор собран статически, часть пакетов (возможно) > ошибочно динамически линкует модули с libpython3.9.so.1.0. Дело в том, что там давно висел патч из Федоры, который статическую либу просто не собирал. Теперь либа собирается, но чтобы сохранить старое поведение, в пакет она не идёт: %files -n libpython3 %_libdir/libpython%pybasever%pyabi.so.* %exclude %_libdir/libpython%pybasever%pyabi.a Кстати, динамическую либу лучше собирать с тем самым флагом, чтобы была несколько быстрее.
Если питон используется из библиотек, то должен линковаться с библиотекой. Очевидно что при линковке с динамической должно занимать меньше места. Я не знаю сколько будет тянуть статическая линковка, возможно что несколько мегабайт. Не останется ли старый питон в статически слинкованных модулях при обновлении системного? В Убунту я вижу статический бинарник и динамическую либу.
(Ответ для ilyakurdyukov на комментарий #38) > Если питон используется из библиотек, то должен линковаться с библиотекой. > Очевидно что при линковке с динамической должно занимать меньше места. Я не > знаю сколько будет тянуть статическая линковка, возможно что несколько > мегабайт. Не останется ли старый питон в статически слинкованных модулях при > обновлении системного? > > В Убунту я вижу статический бинарник и динамическую либу. Нет, я несколько другое имел в виду. Всё нормально, если в ELF-е (чаще исполняемой программе как gdb или gimp какой-нибудь, но может, и в библиотеке) нужен интерпретатор для расширений на питоне, и тогда динамически прилинкована библиотека libpython3. Но есть бинарные модули для питона. (Они используют ABI питона, предоставляемое как библиотекой libpython3, так и standalone интерпретатором, неважно как слинкованным: статически или динамически). Собственно, способ который всегда работает -- оставить модуль недолинкованым с libpython3, тогда он без проблем загрузится при обоих способах и ld.so не будет автоматически подгружать libpython3 (что может вызвать бабах при загрузке изнутри статически слинкованного интерпретатора). Есть подозрение, что в этом списке появились модули, которые ошибочно линкуются с libpython3 вместо недолиновки (что было принято в ALT-е раньше, пока не собрали python3 динамически). Попробую найти в списке пример для демонстрации.
Тогда это и правда может быть проблемой. Хотя скорее всего работать будет, просто будет два питона подгружаться. Статик билд был добавлен: 3.2.2-alt4 28 Mar 2012 Заменён на shared: 3.6.4-alt1 3 Apr 2018 Как линковались эти модули в этом промежутке?
Если модуль будет недолинкован, то каким образом система будет знать, что нужно будет подгрузить libpython? А при загрузке из статического питона - питон должен перекрыть все экспортируемые символы из библиотеки. Могут ли они перемешаться - не знаю. Лучше посмотреть как до 2018-го работало.
Коллеги, если всё скопом забрать у Ильи сперва в сизиф, затем в p10 (и на e2k) не получается (страшно, непонятно, нерешённые вопросы) -- предлагаю вместо "всё в одном и хрен поймёшь" завести и порешать отдельными багами (в которых можно сослаться на соответствующие места этого обсуждения -- "bug 40278 comment NN"): - отключение COMPUTED_GOTOS на текущем %e2k (срочно, важно, несложно); - -O%_optlevel по умолчанию вместо прибитого гвоздями -O2 (важно); - применение патча насчёт labels as values на e2k (неохота тащить форк); - shared vs static по умолчанию. В принципе для переоформления багов и коммитов может хватить и меня, только есть риск, что засвоплюсь (эту багу прочёл уже выйдя из отпуска). (Ответ для Grigory Ustinov на комментарий #15) > Холивар "патчи против регулярок" длится уже давно Это не холивар, а выбор между известными плюсами и минусами двух вариантов. Каждый раз он делается заново -- с учётом конкретики проекта и изменения. (Ответ для Grigory Ustinov на комментарий #18) > > Вы думаете, что всё это должно быть написано в комментариях в спеке? Совершенно точно _не_ должно: в спеке это шум. А вот коммит "Updated Elbrus fixes" (2ebc522457794b150109e8ae42f3775e7ecd6f99) я бы тоже разбил на несколько (e2k-linux-gnu, computed gotos, labels as values, опции/баги профилировки lcc). При этом стоит перенести из comment 16 хоть дословно, хоть в сокращённом переводе на ИТ-латиницу (сославшись на полный вариант) в описание коммита про labels as values. Возможно, проще будет даже объединить его с более точечным и "простым" отключением computed gotos -- именно чтобы вся заваренная каша была описана слитно; возможно, стоит разделить объёмное описание на две части: 1) почему именно применена штатная ручка --with-computed-gotos=no (и при каких условиях её будет пора отключить, здесь стоит упомянуть "mcst#6028"), и 2) что именно делает скрипт (при этом однострочный комментарий в _спеке_ вида "see also ALT#40278/40xxx and commit message for 3.9.6-alt2" полезен). В данном разе добавление e2k-linux-gnu я бы оформил патчем и постарался его заапстримить -- а на sed откатился бы впоследствии, если апстрим заупрямится, но при этом другие новые архитектуры продолжит добавлять (ломая контекст). > > Для любопытных я могу оставить номер бага. > Да, пожалуй. Не просто "да", а обязательно; такие метаданные, когда подробности из головы повылетали, могут сберечь часы и дни раскопок заново даже самому сделавшему. > Выглядит оно мощно! Хороший commit message, см. тж. ядро. :-) Плохие дублируют код, а хорошие задают контекст и объясняют причины/тонкости. (Ответ для Grigory Ustinov на комментарий #23) > (Ответ для ilyakurdyukov на комментарий #22) > > > https://bugzilla.redhat.com/show_bug.cgi?id=556092 > > Мне кажется, что они там ерундой страдают. Гораздо проще удалить файл, > > чем годами поддерживать этот патч. Который еще и static билд ломает, > > а значит вредительский. > Гораздо проще ничего не менять, если никому не мешает=) > Золотое правило мастера "не чини то, что работает". Не пытался вникнуть в причины данного "I've chosen", но фраза про красную шляпу на пустом жбане помнится ещё с тех пор, как эти деятели упаковали как-то /usr/sbin/named нулевого размера в обновления... Считать любого сотрудника редхата априори мастером я бы поостерёгся: рукожопов, напылесошенных по объявлению, там гораздо больше, чем хотелось бы. Ну и даже на мастера бывает недосып, недосмотр и прочая проруха. Сейчас bugzilla.redhat.com на обслуживании, но вообще-то хорошо бы им отписать в тот старый rh#556092, что это "chosen to patch" ломает статическую сборку, даже если им до этого дела нет (как вариант, напомните мне письмом). > Предлагаю подобные отдельные ветви обсуждений выносить в отдельные баги, > чтобы не потерялось и чтобы не путаться в обсуждениях. +1 (Ответ для Ivan Zakharyaschev на комментарий #31) > (In reply to ilyakurdyukov from comment #29) > > > Мне бы такой подход тоже понравился ещё больше. (И послать в upstream, > > > если этот механизм родом из upstream.) > > Пока широкой розничной доступности не будет - это проблема. Потому что > > зарубежному апстриму негде взять железо для проверки патчей. > Но патч без кода, а просто делающий выбор опций в зависимости от моедли > компилятора могут и принять без тестирования. Есть подобные (и не совсем) > патчи ради компиляции на e2k, принятые в другие upstream-ы. Подтверждаю; и ради оптимизации -- тоже.
*** Bug 40750 has been marked as a duplicate of this bug. ***
ping ilyakurdyukov Что там новенького?
(Ответ для Grigory Ustinov на комментарий #44) > ping ilyakurdyukov > > Что там новенького? Что должно быть новенького? Патч я сделал, никто его не принимает и видимо и не собирается.
(Ответ для ilyakurdyukov на комментарий #45) > (Ответ для Grigory Ustinov на комментарий #44) > > ping ilyakurdyukov > > > > Что там новенького? > > Что должно быть новенького? Патч я сделал, никто его не принимает и видимо и > не собирается. Насколько я понял, мы остановились на таске 276773. Комментарий 35. С того момента были "озвучены" пожелания заинтересованных лиц. Вы хотели ревью, вы его получили. Теперь ваша очередь учесть эти пожелания и подготовить таск с опцией --commit. Потому что таск 276773 не упал с EPERM и никто из списка acl не может дать ему аппрув. Я попробую в кратце повторить суть желаемого: Давайте вынесем обсуждение статической линковки в отдельную багу и решим отдельным релизом (не будем вносить коммиты 1ecee6f и e10f1a4 в 3.9.6-alt2) В этом релизе и так много очень хороших изменений, которым давно уже пора быть в сизифе.
Я просил проверить этот билд. В итоге я так и не понял, со всеми ли плагинами оно нормально работает или нет. Мне так никто и не подтвердил и не опроверг. Хотя если раньше со статическим билдом работало - значит и сейчас должно. Запустил на коммит, чтобы был EPERM. Если кто-то хочет всё растащить по отдельным багам - растаскивайте.
(Ответ для ilyakurdyukov на комментарий #47) > Я просил проверить этот билд. В итоге я так и не понял, со всеми ли > плагинами оно нормально работает или нет. Мне так никто и не подтвердил и не > опроверг. Хотя если раньше со статическим билдом работало - значит и сейчас > должно. > > Запустил на коммит, чтобы был EPERM. > > Если кто-то хочет всё растащить по отдельным багам - растаскивайте. Я, к сожалению, не успел всё детально проверить, потому что оказался занят другим.
(Ответ для Grigory Ustinov на комментарий #46) > Я попробую в кратце повторить суть желаемого: > Давайте вынесем обсуждение статической линковки в отдельную багу и решим > отдельным релизом (не будем вносить коммиты 1ecee6f и e10f1a4 в 3.9.6-alt2) > В этом релизе и так много очень хороших изменений, которым давно уже пора > быть в сизифе. На данном этапе, я считаю, хорошая мысль немного отложить статический билд, потому что менять требования к модулям, которые могут быть загружены, надо аккуратно, отслеживая этот интерфейс через формальные зависимости вроде python3.9-ABI (разделить эту на две: можно всякие модули грузить -- предоставляется питоном, собранным динамически с libpython; и нельзя динамически слинкованные модули грузить -- придётся новое завести для статической сборки). А прочие улучшения можно сейчас собрать, ещё раз посмотреть всем заинтересованным и сообща одобрить.
Ну и что всё это значит? http://git.altlinux.org/tasks/283153/logs/events.1.1.log 2021-Aug-17 14:26:06 :: task #283153 for sisyphus started by ilyakurdyukov: #100 build 3.9.6-alt2 from /people/ilyakurdyukov/packages/python3.git fetched at 2021-Aug-17 14:26:05 2021-Aug-17 14:26:07 :: [ppc64le] #100 python3.git 3.9.6-alt2: build start 2021-Aug-17 14:26:07 :: [x86_64] #100 python3.git 3.9.6-alt2: build start 2021-Aug-17 14:26:07 :: [armh] #100 python3.git 3.9.6-alt2: build start 2021-Aug-17 14:26:07 :: [aarch64] #100 python3.git 3.9.6-alt2: build start 2021-Aug-17 14:26:07 :: [i586] #100 python3.git 3.9.6-alt2: build start [x86_64] from /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_runtime.h:12: [x86_64] /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_condvar.h:5:4: error: #error "this header requires Py_BUILD_CORE define" [x86_64] 5 | # error "this header requires Py_BUILD_CORE define" [x86_64] In file included from /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_runtime.h:12: [x86_64] /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_gil.h:15:4: error: #error You need either a POSIX-compatible or a Windows system! [x86_64] 15 | # error You need either a POSIX-compatible or a Windows system! [x86_64] cpp.req: /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_runtime.h: cpp failed, trying c++ mode [x86_64] /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_runtime.h:8:4: error: #error "this header requires Py_BUILD_CORE define" [x86_64] 8 | # error "this header requires Py_BUILD_CORE define" [x86_64] In file included from /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_runtime.h:11: [x86_64] /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_atomic.h:8:4: error: #error "this header requires Py_BUILD_CORE define" [x86_64] 8 | # error "this header requires Py_BUILD_CORE define" [x86_64] In file included from /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_runtime.h:12: [x86_64] /usr/src/tmp/python3-buildroot/usr/include/python3.9/internal/pycore_gil.h:8:4: error: #error "this header requires Py_BUILD_CORE define" [x86_64] 8 | # error "this header requires Py_BUILD_CORE define" [x86_64] --
(Ответ для ilyakurdyukov на комментарий #50) > Ну и что всё это значит? > > http://git.altlinux.org/tasks/283153/logs/events.1.1.log Это всё не мешает сборке. Сборка упала на error: No such file or directory: /usr/src/tmp/python3-buildroot/usr/lib64/libpython3.9.a Я же попросил убрать оба коммита про статическую сборку, потому что они по смыслу идут вместе.
(Ответ для Grigory Ustinov на комментарий #51) > (Ответ для ilyakurdyukov на комментарий #50) > > Ну и что всё это значит? > > > > http://git.altlinux.org/tasks/283153/logs/events.1.1.log > > Это всё не мешает сборке. Сборка упала на > error: No such file or directory: > /usr/src/tmp/python3-buildroot/usr/lib64/libpython3.9.a Видно в конце http://git.altlinux.org/tasks/283153/build/100/x86_64/log
python3-3.9.6-alt2 -> sisyphus: Wed Jun 30 2021 Ilya Kurdyukov <ilyakurdyukov@altlinux> 3.9.6-alt2 - Removed changes from ALT39329, restores -O3 and -g flags (Closes: #40278). - Updated Elbrus fixes. - Enabled optimizations (armh excluded due to test_hashlib crash).
(Ответ для ilyakurdyukov на комментарий #41) > Если модуль будет недолинкован, то каким образом система будет знать, что > нужно будет подгрузить libpython? "Модуль" загружается уже из интерпретатора питона (либо статического /usr/bin/python3, либо встроенного в другую программу с помощью libpython3). Так что тут нет проблемы. > А при загрузке из статического питона - питон должен перекрыть все > экспортируемые символы из библиотеки. Могут ли они перемешаться - не знаю. > Лучше посмотреть как до 2018-го работало. Ну тогда большинство модулей волшебным образом были недолинкованы, а где-то могли требоваться какие-то патчи (и если падение при использовании модуля происходило, это был сигнал мейнтейнеру; а за время динамического питона этих сигналов не было, что могло позволить расслабиться). Например, в p8 список python3-module-* с такой зависимостью невелик. Я посмотрел так: $ hsh --ini ~/hasher2/ --apt-conf /home/imz/.hasher/p8/apt.conf $ ~/hasher2/aptbox/apt-cache whatdepends 'libpython3.5m.so.1.0()(64bit)' А в таком списке для Sisyphus я наугад несколько проверил. Например, в python3-module-PyQt5 вроде всё законно: модули для питона недолинкованы с libpython3, а заисимость берётся из плагинов для qt, которые используют интерпретатор. А вот падение -- вызвано ли оно обсуждаемой проблемой, я не исследовал: $ p=python3-module-CTK; hsh --without-stuff --ini ~/hasher2 && hsh-install ~/hasher2/ "$p" tests-for-installed-python3-pkgs && hsh-run ~/hasher2/ --mount=/proc,/dev/pts -- bash -c "rpm -q $p; rpm -q $p --provides; echo 'Non-importable:'; /usr/lib/rpm/check-python3-provs-importable $p" python3-module-CTK-0.1.0-alt3.git.dc2e1289.x86_64 python3(CTKCommandLineModulesBackendFunctionPointerPythonQt) python3(CTKCommandLineModulesBackendLocalProcessPythonQt) python3(CTKCommandLineModulesBackendXMLCheckerPythonQt) python3(CTKCommandLineModulesCorePythonQt) python3(CTKCommandLineModulesFrontendQtGuiPythonQt) python3(CTKCommandLineModulesFrontendQtWebKitPythonQt) python3(CTKCorePythonQt) python3(CTKDICOMCorePythonQt) python3(CTKDICOMWidgetsPythonQt) python3(CTKImageProcessingITKCorePythonQt) python3(CTKPluginFrameworkPythonQt) python3(CTKScriptingPythonWidgetsPythonQt) python3(CTKVisualizationVTKCorePythonQt) python3(CTKVisualizationVTKWidgetsPythonQt) python3(CTKWidgetsPythonQt) python3(ctk) python3(ctkSimplePythonShell) python3(qt) python3-module-CTK = 0.1.0-alt3.git.dc2e1289:sisyphus+293819.1140.16.3 Non-importable: CTKCommandLineModulesBackendFunctionPointerPythonQt CTKCommandLineModulesBackendLocalProcessPythonQt CTKCommandLineModulesBackendXMLCheckerPythonQt CTKCommandLineModulesCorePythonQt CTKCommandLineModulesFrontendQtGuiPythonQt CTKCommandLineModulesFrontendQtWebKitPythonQt sh: line 1: 183721 Segmentation fault python3 -c 'import CTKCorePythonQt' 2> /dev/null CTKCorePythonQt sh: line 1: 183723 Segmentation fault python3 -c 'import CTKDICOMCorePythonQt' 2> /dev/null CTKDICOMCorePythonQt sh: line 1: 183725 Segmentation fault python3 -c 'import CTKDICOMWidgetsPythonQt' 2> /dev/null CTKDICOMWidgetsPythonQt CTKImageProcessingITKCorePythonQt CTKPluginFrameworkPythonQt sh: line 1: 183731 Segmentation fault python3 -c 'import CTKScriptingPythonWidgetsPythonQt' 2> /dev/null CTKScriptingPythonWidgetsPythonQt sh: line 1: 183733 Segmentation fault python3 -c 'import CTKVisualizationVTKCorePythonQt' 2> /dev/null CTKVisualizationVTKCorePythonQt sh: line 1: 183735 Segmentation fault python3 -c 'import CTKVisualizationVTKWidgetsPythonQt' 2> /dev/null CTKVisualizationVTKWidgetsPythonQt sh: line 1: 183737 Segmentation fault python3 -c 'import CTKWidgetsPythonQt' 2> /dev/null CTKWidgetsPythonQt sh: line 1: 183739 Segmentation fault python3 -c 'import ctk' 2> /dev/null ctk ctkSimplePythonShell qt $
