Оптимизация в питоне?

Берёшь профайлер и оптимизируешь.

Или просто берёшь и начинаешь писать на си. Разработчики пары-тройки питоньих модулей так и сделали.

Это будет оптимизация по скорости работы? Какие еще есть параметры?

Оптимизация в питоне? Где про это почитать можно.

В K&R.

И причем тут С? Как это мне поможет научиться пользоваться профайлером в питоне?

С самых простых вещей, что это такое вообще и зачем и как ее делают

Выкинь python, перепиши на Java. Bioreactor не даст соврать

Когда в Python возникают вопросы оптимизации – программисты начинают выносить ресурсоёмкие части программы в модули на комплируемом языке, чаще всего это C.

Хороший программист на Python обязан знать C хотя бы по той причине, что самая канонiчная реализация Python – CPython написана на нём.

Вы молодец.

Соображать стали, чем отличаются компилируемые (https://ru.wikipedia.org/wiki/JIT-компиляция) языки от интерпретируемых.

Только пока https://ru.wikipedia.org/wiki/HotSpot всё равно побыстрее будет -

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python.html

Вы просто на глазах растёте!

Вот, что значит Ваше общение с умными людьми на ЛОРе.

Там нет оптимизаций. Если упираешься в CPU, то лучше переписать на Джаву, у алгоримического кода скорость будет как у Си.

Моя набухшая Java сначала медленно, но затем всё сильнее и сильнее начала упираться в резинку памяти, пытаясь выглянуть наружу.

Посмотри как пишут все модули которые хотя бы чуть чуть быстрые.

Например https://github.com/numpy/numpy/tree/master/numpy/core/src

Хинт: оно всё на C

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

его изучение у нас даже в программе нет

Далеко ты так не уедешь.

На таком высоком уровне ты ничего не оптимизируешь. Тут работают только оптимизации на уровне алгоритмов.

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

Чем оптимизация отличается от рефакторинга?

Оптимизация проводится с целью снизить потребление ресурсов / ускорения. В сущности это рефакторинг. Но рефакториг может и иные цели преследовать, например покрытие кода докстрингами или какое-нибудь тупое переименовывание неочевидно названных сущностей — тоже рефакторинг.

Вообще, есть мнение, что это противоположные вещи. Ибо оптимизация может и наоборот испортить читаемость. А основная цель рефакторинга именно она.

Но трактуй как хочешь. Лично я не отделяю понятия так однозначно, считаю, что любое улучшение кода с той или иной целью — рефакторинг.

Берёшь профайлер и оптимизируешь

Название софтин - в студию!

Да хоть strace. Иной раз посмотришь, софт 100500 раз перечитывает (не поллит при этом) одни и те же файлы.

Очень просто. Находишь лагучий код на питоне, который много раз вызывается и даёт больше всего тормозов, переписываешь его на C/C++/любом другом быстром ЯП, возможно даже с использованием GPU, если это необходимо и возможно, делаешь обёртку на питоне, работаешь с обёрткой, все медленные вычисления в коде на C

Работодателю тоже будешь про программу и ВУЗ втирать?

Обычно целью. Оптимизация это про то, что надо уменьшить жор ресурсов ПК, памяти там, вычислений, а рефракторинг про то, что надо сделать код читаемым, чтобы с ним люди могли работать. Но очень часто приходится делать и то и другое одновременно, т.к. лаги из-за того что лапшу понимать тяжело бывают, соответственно алгоритм далек от оптимального, что вскрывается на рефракторинге.

Оптимизация это когда программу изменяют чтобы она работала быстрее/потребляла меньше памяти/занимала меньше места. Рефакторинг это изменение программы с целью сделать код программы меньше по объему/понятнее/проще для сопровождения. В обоих случаях функциональность программы остается той же, но в случае оптимизации вы улучшаете программу с точки зрения пользователя, в случае рефакторинга улучшаете с точки зрения разработчика.

JIT-компиляция, это когда программа сначала тормозит и жрет как интерпретируемая, потом жрет еще больше на JIT компилятор в узких местах, а потом тормозит на переходах между интерпретируемых и машинных местах.

Но иногда JIT необходим, например в случае с Java. С одной стороны стандартная библиотека настолько раздута, что интерпретировать это нельзя - будет плохо постоянно опускаться и подыматься на 100 пунктов стека на каждый чих. Потому это нужно компилировать, чтобы компилятор вытер абстракции. Но компилировать заранее в натив тоже нельзя, ведь из-за раздутости Java, SubstrateVM на Hello World работает 90 секунд. 90 секунд Карл!

Значит они все сделали правильно при условии такой раздутости - решили компилировать только узкие места, чтобы одновременно не тратить все 90 секунд, а то и больше, но одновременно не париться о произвоительности не сильно горячего кода.

Получаем отличный результат, можем запинать интерпретируемый динамически типизируемый Python на бенчмарке. Но конечно не .NET Core работающий так же, https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java-csharpcore.html, на большинстве

В питоне наоборот чаще следует жертвовать оптимальностью ради читаемости и удобства, иначе зачем вообще использовать питон?

Золотые слова.

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

SubstrateVM

Не взлетело.

И не взлетит.

Где тут наш стендап-комик stevejobs c «Джокера»?

Да, согласен, не взлетит.

Но символизирует как тяжело компилировать Java

Питон сейчас не компилируется через SVM. В SVM можно запустить только трюфельный интерпретатор, и он будет там работать в режиме интерпретатора. Это, конечно, быстрее CPython (что угодно быстрее CPython), но все равно не огонь.

Рекомендованый воркфлоу при использовании SVM - ты вначале всё разрабатываешь на джаве в нормальном JIT режиме, но с учётом ограничений SVM. А компилируешь только при подготовке релиза на продлайк тестирование и прод.

Вообще, SVM конечно же теоретически может компилировать куда быстрее. Просто там нет опций настройки уровня оптимизации, и оно всегда оптимизирует на максимум. А «максимум» это бесконечный набор всяких разных глобальных оптимизаций, которые непрерывно пилят и разрабы, и все эти студенты, которые теперь защищают на граале свои курсачи, дисеры и тезисы. Почему нет настроек, чтобы оставить условный -O2? Я конечно не могу говорить за них, но есть подозрение, что это просто не самая приоритетная задача. Кому надо - подождет, кому не надо - может проходить мимо.

Но символизирует как тяжело компилировать Java

Моя этот фраза не понимай.

В тесте двоичных деревьев хипстерский недоязычок полностью слил Джаве -

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html

Мои соболезнования.

Не знаешь часом, пропускает ли JVM стандартную библиотеку через JIT? Или она заранее собрана в натив?

Зачем приносить бенчи, в которых джава сливает по всем категориям кроме парочки, при этом пытаясь за нее топить? Это странное самобичевание

binary-trees
source	secs	        mem	gz	        busy	cpu load
Go            25.40	370,688	1005	87.09	86% 86% 86% 85%
Java           8.29	966,764	835	        27.76	86% 80% 86% 83%

«Это фиаско, братан!»(С)

На оправдания и софистику по поводу «не так посчитали», «не те тесты» отвечать не буду, ибо -

«Единственное преступление, которое я не могу себе позволить - это убивать время!» (С)

В том же бенче Go vs Java другие алгоритмы показывают обратное. Это фиаско братан.

Это я ещё С/С++/Rust не брал

Кстати, а чего ты вообще о Go начал? Я его не упомнинал

Какие же и с какой разницей?

reverse-complement

k-nucleotide

regex-redux

binary-trees

Такой хайп и такие скромные результаты по сравнению с «языком прошлого века для офисного планктона»(С)

Релаксируйте.

Надо же, а здесь вообще полная профнепригодность хипстерского недоязычка по сравнению с Java -

https://habr.com/ru/post/424649/

Заключение

Используя одно и то же оборудование REST api приложение Java может 
поддерживать вдвое больше одновременных пользователей, 
чем приложение GO с базой данных PostgreSQL.

Зато хайп сектантов модных недоязычков и понты.

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

Кстати, опять же причем тут Go? Ещё раз, я его не упомнинал. Так же я не ставил под сомнение что горячий код в итоге пройдет через JIT.

Передеть будут первые 10000 циклов, кажется последний раз такая граница была у Java. И получаем кумулятивный эффект ползучей холодности.

Мораль - IDEA лучше никогда не закрывать

Конечно же он пропускает её через джит.

Единственное что ты можешь сделать - собрать shared архив с помощью фичи под названием AppCDS (доступен начиная с JDK 5, в JDK 13 такой архив ещё и может сам пересобираться после перезапуска приложения с учётом того, какие классы были загружены в реальности). Но это не натив, а именно быстро-загружаемый архив с классами, чтобы не ползать по файлухе.

Почему это важно - потому что при старте Hello World компилируется около 1500 классов (в JDK~8) или 1200 (в JDK~13), и даже сам факт поиска такого количества кода на файлухе - это большая работа.

Почему никто не собирает стдлиб в натив и не собирается делать этого в будущем, кажется, хорошо изучена

Проблема с аотом в языках типа джавы и джаваскрипта в том, что он бессмысленный в среднем случае. Аот («натив») хорошо работает только тогда, когда профиль нагрузки у тебя плоский, нагрузка ровно размазана по всеу коду в приложении. Что мягко говоря, не всегда так. Почти никогда не так.

При этом для аота ещё и нормальных GC не завезли, в SVM какой-то скавенджер. Приложухам, которые ворочают терабайтами рамы как-то уже наплевать, какой там профиль нагрузки на код, если мусор не вывозится. В будущем это могут поправить... а могут и нет.

Другая проблема в том, что если нагрузка на приложение неравномерная (что примерно всегда бывает в десктопных приложениях, например), то не существует одного хорошего способа «правильно» скомпилировать приложуху. Приложуха по ходу дела деоптимизируется и пересобирается джитом снова и снова под конкретные ситуации. Прибить её гвоздями к одному и тому же профилю нагрузки было бы просто огромной потерей производительности.

Ещё есть всякие специфичные штуки, что даже если бы ты попробовал скомпилировать все возможные профили всеми возможными способами, устроить настоящий трассирующий компилятор, и так далее. Но надо учитывать, что у нас не абстрактная машина тьюринга, а реальный компилятор, который должен отработать всё это за конечное время и положить это всё в конечный кэш кода. Представь себе мегаморфный вызов метода с 20 параметрами типа Object, куда может прийти что угодно с любым профилем нагрузки - какой должен быть кодкэш, чтобы всё это туда сложить? Если ты возьмешь напишешь элементарную приложуху, какое-то нибудь приложение на Spring Boot и форсируешь JIT компилировать методы сразу же после первого запуска, ты сможешь легко поставить приложение раком минут на десять пока там скомпилируется хотя бы самая база, а в оперативной памяти у тебя место начнёт заканчиваться с такой скоростью, что ты сам первый откажешься от этой идеи. По сути, память будет тратиться в тех же объемах (если не больше), как жесткий диск при компиляции C++ - гигабайтами.

Как-то так. На практике, в почти всех современных рантаймах JIT победил. Собственно, создатели Джавы, и в особенности Cliff Click приложили к этому руку и доказали, что JIT не только имеет право на жизнь, но и самый лучший инженерный компромисс для динамических рантаймов. А потом уже и все остальные современные рантаймы, вроде V8 для JS, эту идею поддержали у себя.

Я привел фактические данные.

С пруфами и графиками.

А поток слов и сознания без конкретных измерений меня не интересуют.

Каким образом победивший JIT победил, но не в С и С++. Для них нету JIT работающего быстрее натива. Почему там не парятся с тем какой кодокеш у Object и он там всегда быстрый?

Например ты сам привел пример с десткопом и там мы видим как раз как тяжко работается Java, хотя по твоим словам именно сборка и пересборка с PGO должна дать преимущество

При этом для аота ещё и нормальных GC не завезли

Вкорячить от Go разве нельзя? Его характеристик хватает чтобы на него переехало тонны облачной инфраструктуры и не жаловались на GC как на проблему. На что угодно другое жалуются, но не на GC

Проблема в том, что в общем случае C и C++ не быстрее джавы по скорости. Можно писать джаву, такую же быструю, как C/C++, но она будет дичайше некрасивая. Даже с Java 15 (?) когда введут value objects, records и всё такое - она всё ещё будет выглядеть как низкуровневое говно.

Можно писать такой же красивый C++ как джава, но он будет дичайше тормозный, особенно в debug сборке (тут нужно вспомнить всё ещё тлеющий срач про то, что C++20 ranges в debug режиме работают в 10+ раз медленней аналогичного кода на циклах, и разработчики не собираются это чинить).

Про что-то подобное даже Страуструп писал, что сейчас мы поднапряжёмся и сделаем C++ почти таким же быстрым как Haskell. (Haskell в паттерн-матчинге и алгоритмах на графах безумно быстрее, чем говнокод на C++, состоящий из чистейших паттернов Observer, поэтому Страуструп хотел запилить кусок хаскеля в C++)

Сегодня разработчики хотят писать так, чтобы перформанс был с точки зрения продуктивности разработчика, а не с точки зрения продуктивости кода. Поэтому дефолты, принятые в джаве и джаваскрипте им ближе. Поэтому код, написанный одними и теми же людьми, с одними и теми же ценностями на Java и C++, будет быстрей работать на Java, ВНЕЗАПНО.

Вкорячить от Go разве нельзя?

Тот GC который в SVM даже лучше, чем гошный. Проблема в том, что и он, и GC в Go - полное говно. Гошный GC хвалится тем, что супер быстрый. Почему он такой быстрый? Да потому что он не делает НИЧЕГО. Загрузи в Го данных на терабайт, начни их там в быстром темпе двигать, и посмотри, какое мучение с ним случится :)

А в джаве есть Shenandoah и ZGC, которые низкопаузные (условно почти без остановки мира) и специально заточены на то, чтобы иметь дела с терабайтными хипами. Но это рокет саенс, их не будет в обозримом будущем на SVM.

На что угодно другое жалуются, но не на GC

так чо, много ли тех, у кого приложухи держат на себе терабайты памяти?

Ну и да, я не понимаю, чего вы все так прикипели к перформансу. Тут что, каждый встречный поперечный - Google?

Да, 90-летние джедаи могут писать на C++ гиперкластеры на Windows 95. Да, джависты могут вбухать миллиарды бабок на разработку супер GC и JIT, которые будут выполняться сильно быстрее на озверевших объемах данных и бесконечных фермах серверов

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

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

Можно писать такой же красивый C++ как джава, но он будет дичайше тормозный

Не, на сайте https://www.rust-lang.org/ посоны говорят что написали C++ такой же красивый как Java и ничего не тормозит.

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

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

Поэтому код, написанный одними и теми же людьми, с одними и теми же ценностями на Java и C++, будет быстрей работать на Java, ВНЕЗАПНО.

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

Проблема общения с представителями Java коммнюнити в том что они верят в какие-то невразуменные 1000 оптимизаций, которые заботливая Java делает пока ты спиш, обняв мишку. ТЫСЯЧА ТЫ ЧЕ. Так можно кого угодно забодать страшностью высказывания. В рамках разговора невозможно проверить что это такое, зачем и какая реальная польза по сравнению с тем что LLVM делает с С++ полностью AOT.

такой же красивый как Java

macro_rules! diagnostic_method {
    ($name:ident, $level:expr) => (
        #[unstable(feature = "proc_macro_diagnostic", issue = "54140")]
        pub fn $name<T: Into<String>>(self, message: T) -> Diagnostic {
            Diagnostic::spanned(self, $level, message)
        }
    )
}
pub struct Context<'a> { _marker: PhantomData<fn(&'a ()) -> &'a ()> }

fn arg_local_refs<'a, 'tcx: 'a, Bx: BuilderMethods<'a, 'tcx>>(
    bx: &mut Bx,
    fx: &FunctionCx<'a, 'tcx, Bx>,
    memory_locals: &BitSet<mir::Local>,
    va_list_ref: &mut Option<PlaceRef<'tcx, Bx::Value>>,
) -> Vec<LocalRef<'tcx, Bx::Value>> {
   let ty = if let (true, &ty::Ref(_, ty, _)) = (by_ref, &ty.sty) {
       ty
   } else {
       ops = &ops[..ops.len() - 1];
       ty
   };
}

быструю, как C/C++, но она будет дичайше некрасивая. Даже с Java 15 (?) когда введут value objects, records и всё такое - она всё ещё будет выглядеть как низкуровневое говно.

«красивый» код - это удел или зеленых или очень давно остановившихся в развитии недопрограммистов.

Ну и да, я не понимаю, чего вы все так прикипели к перформансу. Тут что, каждый встречный поперечный - Google?

Да я вообще за наоборот топлю. Это ты про терабайт памяти начал, потому GC жабы самый лучший на планетке. Хотя в 99% задач нужно чтобы GC был как у Go - делал ничего.

Вот я пишу docker run или запускаю etcd на гигабайт. Была бы там Java с божественным GC для того чтобы 1TB гонять, то моя бы утилита запускалась долго и меня бесила, а etcd сожрал бы 4.

Где пруфец что качества GC джавы более практически полезны? При том что ее ругают за GC, а в случае Go народ в большинстве вроде не догадывается что там какие-то еще паузы могут случиться.

таких вот случаев мое высказывание выше не касается. тут проблема не в «красоте».

Такая простыня есть в любом ЯП, а вот я посмотрел свой код, там чистенько и Hindley-Milner мне все типы посчитал сам, статически

Ну вот и С++ красивый, виноваты простыни.

дефолты, принятые в джаве и джаваскрипте им ближе
джаваскрипте

wat?