Компания Canonical опубликовала результат оценки изменения производительности при пересборке пакетов с включением оптимизации на основе результатов профилирования кода (PGO - Profile-guided optimization), позволяющей генерировать более оптимальный код на основе анализа особенностей выполнения программы. В ходе проделанной работы был сделан вывод, что включение PGO-оптимизации позволило на 5-7% снизить нагрузку на CPU и ускорить время сборки...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62262
Питон раза в 2 ускоряется в пго билде с парой дополнительных флагов.
Самый лучший способ ускорить питоновские приложения -- это переписать их на другой язык.
Это надо переписывать. Поверь, бесплатное ускорение это очень выгодно. А если пользователь ждёт завершения, ещё и приятно.
только оно не бесплатное
> только оно не бесплатноеНичего не надо делать, пару команд в сборочный скрипт добавить. Прочее ускорение потребует рефакторинга кода, изменения структур данных, замены компонентов и так далее. Добавить пару команд и задействовать компилятор более полноценно, это, фактически, бесплатно. И максимально универсально.
>> только оно не бесплатное
> Ничего не надо делать, пару команд в сборочный скрипт добавить. Прочее ускорение
> потребует рефакторинга кода, изменения структур данных, замены компонентов и так далее.
> Добавить пару команд и задействовать компилятор более полноценно, это, фактически, бесплатно.
> И максимально универсально.PGO нифига не бесплатно: чтобы это реально работало надо профиль отстроить. И это ессно жрет ресурсы.
Переписывать дорого. А надеяться на всякие хаки которые позволяют выжать из питона ещё десяток процентов, при том что он отстаёт от компилируемых языков в десятки раз и не умеет в многопоточность - глупо. Единственная правильная стратегия - на питоне ничего не писать с самого начала.
>Это надо переписывать.На питоне изначально не надо писать, тогда и переписывать не придётся
Быстро, удобно, есть готовые компоненты приемлемого уровня для решения большинства задач. Единственно, не очень приятно асинхронный код отлаживать (интерпретатор любит врать и подсовывать совершенно несвязанные исключения в посторонних местах). Это прямо боль до сих пор.
Время первого запуска возрастает до бесконечности. Не самый лучший способ.
Ага, на ассемблер, но есть нюанс...
Ассемблер может что ускорить только путем срезания острых углов дополнительных проверок. По факту путем снижения безопасТности.
> Ассемблер может что ускорить только путем срезания острых углов
> дополнительных проверок. По факту путем снижения безопасТности.Как показала соседняя новость с питонокодом в needrestart'е убунт - там тоже с безопасностью не очень оказалось. Оказывается ненужные проверки можно срезать и на питоне. Ну и что что всякая лабуда атакующего под рутом в результате выполняется?! Зато прогер времени себе сэкономил на кодинге проверок!
Не только, он ещё может и манипулировать памятью так как ни в одном языке вы это не сделаете. Только человек не компилятор. Если человек где-то маленький участок кода и может оптимизировать, а вот огромный кусок кода переработать человеку уже не так просто. Именно поэтому и нужны языки программирования.
> Самый лучший способ ускорить питоновские приложения -- это переписать их на другой язык.Редхат что-то такое и начал наконец для своего пакетника. Правда, на цать лет позже всех остальных. Энтерпрайзный софт как он есть - кормить клиентуру заплатившую миллионы максимально глюкавым, тормозным и непотребным гуано, "с лопаты". Энтерпрайз в интерьере.
В то время как даже комьюнити смогло написать apt на плюсах нормальных, так что работает в разы шустрее и RAM жрет в разы меньше.
Лучший способ написать хорошее приложение - это сначала написать плохое. Прогресс невозможен без ошибок.
Нет. Написав плохое приложение, вы не напишете хорошее, если не будете к этому страмиться. Поэтому лучший способ написать хорошее приложение - стремиться написать хорошее приложение.
> Питон раза в 2 ускоряется в пго билде с парой дополнительных флагов.Это вы по тем графикам вывод сделали? Обожаю графики где ось начинается не с ноля, сразу иследователи такие важные и нужные. А реально эти 5% разглядеть на фоне нормального графика...
Нет конечно, эти лалки открыли для себя пго 10 лет спустя после всех остальных. Именно поэтому какой-то смысл нести деньги есть только тем, у кого имеются разрабы. Ну, хотя бы, и шляпе. А эти имитируют бурную деятельность на самом деле.
> Нет конечно, эти лалки открыли для себя пго 10 лет спустя после всех остальных.
> Именно поэтому какой-то смысл нести деньги есть только тем, у кого имеются разрабы.
> Ну, хотя бы, и шляпе. А эти имитируют бурную деятельность на самом деле.Шляпа как видим тоже - та еще шляпа. Ибо теперь это IBM и ваш чемодан денег им уже не очень интересен, сдалась им мелочевка всякая. Вот если вы товарный состав подгоните - так и быть, вы их клиент.
А без этого можете бесплатно покамикадзить тестовым манекеном в федоре. Ух какая благодать! А, вот, еще центос стрем - для манекенов переживших первый раунд краштестов.
Скачал Python 3.10, и он ПО УМОЛЧАНИЮ собирался с PGO (Скомпилился, долго выполнял тестовые расчеты, перекомпилился используя результаты профилирования)
Да, но периодически проблемы с компиляторами всплывают до сих пор. Корпы хотят, чтобы собиралось шлангом, и ломают сборку гцц. А бинарные билды часто не оптимизированы, в той же федоре стали нормально собирать только несколько лет назад.
Так Федора сама по себе тестовая сборка, зачем там была нужна оптимальность непонятно.
У них почти все скрипты на питоне были. Включая пакетный менеджер. Пго это бесплатное ускорение по сути, никаких недостатков (ну, кроме времени компиляции и необходимости гонять профилирование).
> У них почти все скрипты на питоне были. Включая пакетный менеджер. Пго это
> бесплатное ускорение по сути, никаких недостатков (ну, кроме времени
> компиляции и необходимости гонять профилирование).Я наелся такого ускорения от редхата и свалил на дебианы и убунты. Потому что делать микро-VM по приципу 1 VM на сервис когда пакетник жрет больше RAM чем сервис - ну вот ой, нерационально.
Как мне кажется, за цать лет транснациональная корпа могла бы разок сделать пакетник нормально а не маяться такой отборной дурью вместо этого.
Как только ты свалил, они с yum перешли на dnf.
Наверное надо сказать тебе "спасибо!" или поругать что так долго не уходил :)
> Как только ты свалил, они с yum перешли на dnf.А до этого они перешли на yum c up2date. Хрен редьки не слаще. Что так дрянь что сяк. Через цать лет до них даже что-то доходить стало.
Но попробовав apt мне что-то вон то юзать уже совсем не хотелось. От слова вообще.
> Наверное надо сказать тебе "спасибо!" или поругать что так долго не уходил :)
Даже не знаю. Но вот что я знаю - так это то что технология жива теми кто ее практикует. И в этом смысле мы посмотрим какое семейство технологий победит :)
По-моему, всё что угодно лучше, чем apt. Это эталонный набор костылей, подпёртых фекалиями.
Задача не ускорить сам Python, а ускорить сборочное окружение, собирающее Python и другие пакеты.
-fno-semantic-interposition ?
Да, -fno-plt и -fdevirtualize-at-ltrans ещё. Раньше, помню, -fwhole-program давала хорошую оптимизацию, но там не универсально и только сишные проги собирались в итоге. А так я -fipa-pta тоже использовал универсально, но лто становится несколько неподъёмным для больших прог, решил отказаться.
Ещё интресно, какой эффект от включения оптимизаций под конретный процессор.
Поставь Генту -- узнаешь.
https://www.phoronix.com/news/Intel-Linux-3888.9-Performance
Ничего эффективнее распределенной компиляции еще не придумали. В условиях технологической отсталости - это единственный способ повышения скорости сборки пакетов. ICECC - рулит.
Это такой намек что бомжу и пачка P4 - билдферма? Электричества она на билд жрет - немеряно, увы и ах.
> Это такой намек что бомжу и пачка P4 - билдферма? Электричества она
> на билд жрет - немеряно, увы и ах.в данном случае - пачка китайских недоделков на risc-v
электричества эти кипятильники сожрут разумеется не меньше чем тот p4, зато крута, шва6одка и все такое.
В газовобогатой стране с газовыми ТЭЦ/ТЭС электричество не проблема.
охрана этих тэс больно дерется при попытке сп-ть электричество. А счета за него таки проблема.
> в данном случае - пачка китайских недоделков на risc-v
> электричества эти кипятильники сожрут разумеется не меньше чем тот p4, зато крута,Ну не, у этих - ядра мелкие, а техпроцессы относительно дубовые, утечек нет особо. И реклок они в отличие от как правило - умеют.
> шва6одка и все такое.Ну так вон китайцы и накопипастили уже алибабовских ядер занедорого - и пошли продавать! А ты можешь накопипастить ядер P4 и тоже иди продавать, если все так офигенно. Озолотишься же :)
> Ну не, у этих - ядра мелкие, а техпроцессы относительно дубовые, утечек нет особо. И реклок они
> в отличие от как правило - умеют.и когда тебе надо на этом что-то _компилять_ - все это идет по п-де, и вся гирлянда отлично светится в темноте.
> Ну так вон китайцы и накопипастили уже алибабовских ядер занедорого - и пошли продавать!
ну раз немамонты покупают - чего б им воздух шва6одки и не продать занедорого.
> А ты можешь накопипастить ядер P4 и тоже иди продавать, если все так офигенно.
я уже купил свой двуксеон из списанных деллов выковыриваемый, он пока нормально работает, и в состоянии даже побыстрому что-то скомпилять сам для себя, если б было зачем.
(да, внезапно, китайцы и такое тоже умеют)
Бить надо за такие графики с отсеченным нулем. Желательно не только по лицу. Там разница всего на 5-6%, но график сделан так чтобы потрясти воображение разницей на глаз этак на 50%. И только внимательный рассмотрит оси, начнет чего-то подозревать и потом наткнется на эти самые скромные 5% под рисунком. Для понимания достаточно было бы одной простенькой таблички вместо всех этих 4-х графиков.
Какая разница, они же не продают эти PGO-оптимизации.Во-вторых какой тогда смысл в графике, если разницу между столбцами надо через лупу наблюдать?
Ты на правильном пути, мой юный падаван. График не нужен.
> Сборочные работы, ранее выполняемые за сутки, при задействовании PGO-оптимизации стали выполняться на два часа быстрееЯ конечно понимаю что большинство местной аудитории гуманитарии и в расчеты не обучены и округляют в зависимости от фазы Меркурия. Но как 5% ускорение дало 2 часа быстрее когда при самых грубых расчетах это 1 час. А при чуть более точных 1 час 12 минут? Да даже округление округления до 6% ну никак не даёт морального права округлять до 2 часов.
60*0.07*24 = 100.8 мин.
Подгонять под результат меня и в школе и институте учили, но на графиках явно пишут что там 5% 2 часа это либо менеджера обмануть или менеджер кого-то пытается обмануть или препода обмануть, но зачем?
> Подгонять под результат меня и в школе и институте учили, но на
> графиках явно пишут что там 5% 2 часа это либо менеджера
> обмануть или менеджер кого-то пытается обмануть или препода обмануть, но зачем?performance review сам себя не пройдет.
А может они померят разницу не в виртуалке? Да не, бред какой-то
я что-то вообще не понял кто у них на ком стоял. Они _виртуалку_ пересобрали с pgo чтобы внутри пересобирать что-то с чем-то ? Или qemu? Или вот что? Чтобы - что?
В общем, какой-то васян похоже просто развлекался от нечего делать, но выдал на гора целое "исследование" ни о чем.
Да, пересобрали виртуалку, в которой собирают пакеты под risc-v (для дистриба на risc-v).
Оказалось чуть быстрее.
Зачем собирать питон когда его можно скачать?
Поставь Gentoo по классике, поймёшь.
> Поставь Gentoo по классике, поймёшь.Ога, когда система портажей на этом самом питоне с очередным питоном вдруг не станет работать - ты познаешь тао во всей его красоте. Или это дао было? :)
> когда его можно скачать?А вдруг там троян? Ну и оптимизаций нет под себя
А вы реально смотрите весь код каждого пакета перед компиляцией? Может проблема в том что нет доверенного источника такого пакета? Вот каждый что-ли должен перепроверять один и тот же код? И это при том что у каждого разный опыт и знания касательно безопасности.
> Вот каждый что-ли должен перепроверять один и тот же код?Да. Это как доказательство теоремы. Можно асистентом прувером воспользоваться еще.
Ну.... играл я с этим когда-то. Но в моих непредсказуемых случаях от него толку было ещё меньше. Лучше векторизацию подкрутить было. Но в целом вещь нужная.
Самый быстрый способ сборки есть но он не кому не доступен , но когда будете готовы в это влить денег то получите эту сверх штуку
> Самый быстрый способ сборки естьЕсть. Apt-get называется. Суть сводится к тому что проц по черному грела - билдферма. А остальным осталось скачать и распаковать :)
В Debian такие оптимизации еще нескоро попадут? А в Arch уже попали?
PGO-оптимизация - это как CD-диск, так писать не грамотно.
Таки, или PG-оптимизация, или PGO, CD или C-диск.
Чет я не понял, каким это образом PGO ускоряет сборку, это ведь дополнительные шаги сборки, плюс код выполняется под профайлером чуть медленнее. Если только выигрышь за счёт скорости выполнения юнит и интеграционных тестов, но что-то я слабо верю, что эти тесты гоняются при сборке дистрибутива, иначе, ни про какие сутки там речь бы не шла, один только OpenSSL полчасика собирался бы.Такое ощущение, что инженеры Canonical где-то изнасиловали журналистов, осталось понять где и чьих.
В оригинальной новости ни слова про улучшение скорости сборки, значит -- пострадали журналисты со стороны OpenNET. В статье говориться, что время сборки осталось приемлемым, несмотря на эмуляцию и внедрение оптимизации, а возможным оказалось, за счёт того, что вместо кросс-компиляции, по историческим причинам применялся не эффективный с точки зрения времени сборки бинарников подход со сборкой внутри qemu виртуалок.
> В оригинальной новости ни слова про улучшение скорости сборки,Как это нет, а это что "We saw average CPU utilization and build time improvements of around 5-7%, which is significant especially when we consider that Launchpad performs several builds per day."
И на всех графиках отражено именно "build time".
Читайте новость внимательнее "Разница производительности оценивалась для QEMU, собранного с опциями по умолчанию и с включением PGO".С PGO собран QEMU, в котором выполняется сборка. Больше производительность эмуляции в QEMU -> меньше время занимает сборка в виртуальной машине.