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

Любая сущность - это класс. В библиотеке Apache Camel как сейчас помню около 7000 классов

Горе от «ума».

И тут C++, в котором в принципе ты тоже можешь сделать приложение на миллион классов.

Почему не триллион?

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

«Чудный код» и «чудный» run-time /лучше вообще отказать в выполнении всего кода/.

Ныне хорошая технология как в игре в футбол «Кто выще бье, тот краще грает».
Если код от Apache, Microsoft, ..., то все должны упасть на колени и рыдать от счастья.

Абстракции C++ не бесплатны

Под бесплатными абстракциями в С++ подразумевается что они компилируются в максимально возможно эффективный машинный код и ничего больше.

Пора бы придумывать шуточки про C++,

Давно уже придумали https://hsto.org/storage/27ed4c0b/74066c8b/b0ab8b5b/fb2afe88.png Но C++ далеко не единственный медленно компилируемый язык, та же Scala и фору ему даст. Haskell и rust тоже не быстро собираются. Наверно из сопоставимо сложных языков только D быстро компилируется.

Под бесплатными абстракциями в С++ подразумевается что они компилируются в максимально возможно эффективный машинный код и ничего больше.

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

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

Проблема в том, что в общем случае C и C++ не быстрее джавы по скорости.

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

Но C++ далеко не единственный медленно компилируемый язык, та же Scala и фору ему даст. Haskell и rust тоже не быстро собираются. Наверно из сопоставимо сложных языков только D быстро компилируется.

Ничего не скажу про компиляторы Rust и Scala. Haskell, действительно, довольно медленно компилирует один модуль, причем, с оптимизицией примерно в два раза дольше, чем без нее. Но нужно понимать, что модуль хаскеля обычно содержит намного больше функционала, чем очередной модуль класса в C++ на 40 строк.

Второй момент - системы сборки хаскеля. Само «ghc -O2 source.hs» отрабатывает довольно быстро, но пакетные менеджеры собирают stage0 по сто раз и используют медленный конфигуратор, из-за чего сам ghc работает 20-25% времени:
http://neilmitchell.blogspot.com/2019/03/ghc-rebuild-times-shake-profiling.html

в яве нет value типов, нет указателей, нет move, и нет возможности работать почти не выделяя память в куче, только на стеке

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

На самом деле основная проблема Жавы - это сборщик мусора и принциапиальная невозможность ручного управления памятью. Кресты могут работать даже без Copy-on-Write и подсчета ссылок, но Java в принципе не умеет подобного.

Но C++ далеко не единственный медленно компилируемый язык,

Кто не умеет правильно создавать и использовать хэдыры, прекомпиляцию, ... /и не только/, тем всегда - «ЯЙЦА МЕШАЮТ».

Еще раз.
Самая большая проблема у «горе» C++ программистов - «ЯЙЦА МЕШАЮТ»

На хабре имеются не плохие статьи по вопросам оптимизации скорости компиляции и сборки проектов на C++.

Приведу простейший пример.

Скажем решил C++ программист использовать прекомпиляцию.
Поместил в stdafx.h хэдэры и «думает», что все ok.
Дудки.
Нужно еще для всех cpp в проекте установить правильно опцию «Precompile Header» /для Visual Studio/.

Кто не умеет правильно создавать и использовать хэдыры, прекомпиляцию, ... /и не только/, тем всегда - «ЯЙЦА МЕШАЮТ».

Хорошо, ты сократил время компиляции на 30% за счет прекомпилированных заголовков. Дальше что? Ты все равно остаешься с адовым тормозом.

Хаскель позволяет делать полностью императивные операции, но выглядит такой код ужасно, потому в таком стиле стараются не писать.

Да причем тут. Речь о том, что хаскель фейлится на том, на что якобы изначально заточен. Пара цитат из статьи (напоминаю, чел 20 лет отдал ФП)

Долгое время сообщество функционального программирования потрясало замечательно короткими реализациями алгоритмов решета Эратосфена и quicksort. Их даже годами преподавали студентам. И только спустя многие годы пришло понимание, что эти реализации не соответствуют исходным алгоритмам. Мелисса О'Нил (Melissa O’Neill) даже опубликовала научную статью, исправляющую решето Эратосфена в Хаскеле. В частности, ее настоящее решето требует в сто раз больше кода, чем ошибочная оригинальная версия. То же справедливо и для quicksort'а, где «элегантная» двухстрочная версия на Хаскеле более чем в 1000 раз медленнее версии Сэджвика на C, потому что Хаскель делает глубокую копию списков на каждом вызове quicksort'а, портя к чертям асимптотическую сложность оригинального алгоритма Хоара.

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

Хаскель норм, просто GHC плохо оптимизирует.

На хабре имеются не плохие статьи по вопросам оптимизации скорости компиляции и сборки проектов на C++.

Несколько советов о том, оптимизировать скорость компиляции проектов на C++:
- используйте шаблоны только по крайней необходимости. Откажитесь от STL во многих модулях, и от Boost во всех модулях своего проекта;
- определеяйте общие структуры в простом виде в отдельных файлах, а реализацию функций объединяйте в крупные файлы не больше 10-20 тыс строк;
- начните писать на C++ как на C.

еще раз

Мелисса О'Нил (Melissa O’Neill) даже опубликовала научную статью, исправляющую решето Эратосфена в Хаскеле. В частности, ее настоящее решето требует В СТО РАЗ БОЛЬШЕ КОДА, чем ошибочная оригинальная версия.

Это фейл GHC?

Хорошо, ты сократил время компиляции на 30% за счет прекомпилированных заголовков.

Solution с тринадцатью проектами 72MB исходников компилируется и собирается быстро.
Даже если проект будет весить 200 MB ни чего тормозить не будет.
У меня так /как там в других вселенных не знаю/.

Очквидно я про

Хаскель делает глубокую копию списков на каждом вызове quicksort'а

На хабре /не помню название статьи/ ребята рассказывали как путем всяческих оптимизаций достигли того, что их «монстр» стал
компилироваться в несколько минут, а не часов.
Видел проекты в которых Boost ну вовсе не нужен ...

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

Компилирует машина, это дешево.

затруднение отладки

Тут да, баги ловит программист, это дорого.

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

Программист и не должен такого подсказывать, ибо это очень высокоуровневый язык. Это же не Си какой-нибудь.
Не надоело за компилятор работу выполнять?
Надо по ходу свой компилятор писать и реализовать свои идеи, которые почему-то не сделали в GHC. Ибо этот позор уже надоел.

Ибо этот позор уже надоел.

Sorry /нравится этот эпизодик из фильма/.
https://www.youtube.com/watch?v=lUV9W9ndorw Это какой-то позор

Есть глупый анонимус, несущий херню в интернетах. Акстись, тут дети читают.

Не надоело за компилятор работу выполнять?

Подход «я тут надевелопил, а ты крутись как хочешь» только в теории хорош. Компилятор даже в теории не может распарсить все хотелки девелопера, приходится ограничивать полет фантазии ограничениями языка. И даже в песочнице языка можно накуролесить так, что никакая математика не спасет.

Premature Optimization Is the Root of All Evil, поэтому с одной стороны да, излагай свою девелоперскую мысль как умеешь, но с другой стороны если вы с компилятором где-то не поняли друг друга, от чего страдает конечный результат, инструменты оптимизации должны быть под рукой.

Долгое время сообщество функционального программирования потрясало замечательно короткими реализациями алгоритмов решета Эратосфена и quicksort. Их даже годами преподавали студентам.

Не моя вина в том, что дауничи с профессорскими званиями суют студням сами не знаю что. Я, например, писал quicksort Хоара, и сразу заметил, что известный алгоритм на хаскеле из интеренета не является этой сортировкой. Если же до какого-то слоупока спустя многие годы пришло понимание, то какова здесь вина хаскеля? Есть классический функциональный mergesort, который идеально подходит под хаскель и имеет масштабируемость наравне с quicksort - сколько лет этим слоупокам нужно будет еще, чтобы до них «пришло понимание», что mergesort лучше quicksort-а в хаскеле?

Во-вторых, еще раз: хаскель допускает императивное программирование, и quicksort можно написать на хаскеле с производительностью, близкой к Си, но это будет выглядеть некрасиво.

Solution с тринадцатью проектами 72MB исходников компилируется и собирается быстро.

Что такое «быстро»? Меньше, чем за день? Мой прошлый проект на делфи весом в 70 Мб собирался+линковался за 5 минут, и то эту цифру можно сократить минимум вдвое, если поотрывать руки некоторым кодерам, которые его писали.

Во-вторых, еще раз: хаскель допускает императивное программирование, и quicksort можно написать на хаскеле с производительностью, близкой к Си, но это будет выглядеть некрасиво.

И смысл?

Еще раз - это будет не тот хаскель, который заявлен. Тётечка вон, переписала решето Эратосфена как положено, и от былой «выразительности высокоуровневых конструкций» осталась шляпа.

Что такое «быстро»? Меньше, чем за день?

Time Elapsed 00:02:13.92

На хабре /не помню название статьи/ ребята рассказывали как путем всяческих оптимизаций достигли того, что их «монстр» стал

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

Что за монстр? Вот этот, что ли?
https://habr.com/ru/company/pt/blog/171801/

176 проектов C++ и C# (в соотношении приблизительно 60% к 40%);
18 000 файлов (> 3 млн строк);
сервер (8 CPU, обычный диск на 10 рейде HDD, 12 ГБ ОЗУ);
Все это собиралось 12 минут.

То есть, порядка 90-100 минут времени ядра собираются все проекты. При помощи софтовых манипуляций им удалось снизить реальное время до 5 минут. А теперь сравни с дельфовым, который те же 3+ млн строк собирает за 5 минут времени ядра - примерно в 8 раз быстрее оптимизированной сборки крестов.

Time Elapsed 00:02:13.92

Коров прошло - что это значит? Два часа реального времени компилировалось, или что?

Компилирует машина, это дешево.

Труд машины по компиляции дешев, а труд программиста, который ничего не делает во время компиляции - намного дороже.

Компиляция и сборка прошла за две минуты и тринадцать секунд.

Да эта статья.
Спасибо!

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

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

Компиляция и сборка прошла за две минуты и тринадцать секунд.

То есть, дольше, чем в делфи. О чем разговор?

труд программиста, который ничего не делает во время компиляции - намного дороже.

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

Как правило. Исключения бывают. Но в целом проблема надуманная.

72MB исходников компилятся и собираются С НУЛЯ за 2 минуты.
Это что много?

72MB исходников компилятся и собираются С НУЛЯ за 2 минуты.

Это что много? Для крестов - это весьма быстро. Ты не указываешь конфигурацию сборки, сколько строк в этих исходниках, потому я подразумеваю 3+ млн строк и сборка в 8-16 потоков, и для крестов такой результат - вполне приемлимая цифра. Правда, только для крестов. Си собирается намного быстрее, паскаль собирается намного быстрее.

В каком-то языке можно клепать дермо, не парясь о типах и высвобождении памяти, и иметь производительность

ну раст жи, не? )

Так о чем разговор?

Разговор о том, что selling point хаскеля это простота и элегантность высокоуровневых абстракций. Которые при столкновении с реальностью стремительно превращаются в тыкву. Не припомню, чтобы ФП вообще и хаскель в частности позиционировались как-то иначе. Если даже в минимальных задачах приходится руками раскручивать все красивые слои до уровня брейнфака, то возникает вопрос - а смысл?

«Не могу ничего делать, у меня компиляция» - это шутка. Проект целиком собирается на билд-серверах

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

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

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

ну раст жи, не?

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

Разговор о том, что selling point хаскеля это простота и элегантность высокоуровневых абстракций. Которые при столкновении с реальностью стремительно превращаются в тыкву.

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

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

Ты цитируешь дебилов и опираешься на их мнение. В минимальных задачах не нужно раскручивать руками ничего до брейнфака - нужно просто использовать моск.

Си собирается намного быстрее, паскаль собирается намного быстрее.

После компиляции с нуля задержек вообще нет.
Это при относительно правильного расклада хэдэров и зависимостей.
Можно было бы добиться и более быстрой компиляции и сборки, но разовая задержка в две минуты меня вполне устраивает.
Я же не футболист, у которых - «Кто выще бье, тот краще грает».

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

Ща набегут растоманы и побьют )

Ты цитируешь дебилов и опираешься на их мнение.

У меня просто нет лишних 20 лет, чтобы вкурить истинный дзен. Приходится опираться на мнение людей, которые эту кашу ложками хлебали, долго и вдумчиво. Они дебилы? Возможно. Но тогда возникает другой вопрос - а как на всей этой радости пилить простым и незатейливым девелоперам, без затей? Если для запила какой-нибудь там сантехники нужна степень доктора наук, то у нас большие проблемы. Ибо выкормить нужное количество докторов не представляется возможным.

разовая задержка в две минуты меня вполне устраивает.

https://habr.com/ru/company/pt/blog/171801/
Этих людей задержка в две минуты тоже устраивает. Правда, для того, чтобы снизить время с 12 минут до 1 3/4 минуты, им пришлось:
- отключить создание отладочной инфы;
- переработать механизм сборки проекта;
- поставить SSD RAID0 x 7;
- использовать процессор 32 CPU x 3 GHz вместо восьми ядер.
И все это только для того, чтобы перевести время сборки не самого большого проекта в комфортные рамки. С этим дерьмом сталкивается любой начинающий крестописатель, который выясняет, что на одном-двух ядрах какой-то средненький проект на миллион строк компилируется целые двадцать минут, что есть ни разу не комфортное время. И уже либо мощный ноут, либо сеточка с билд-сервером, и прочая порнография, и всё это для решения одной единственной проблемы - С++ кошмарно долго компилируется.

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

Ща набегут растоманы и побьют

Что не так? Раст довольно сильно ограничивает в работе с памятью. Даже если я знаю, что указатель будет правильный - я не могу его просто так передавать, потому что он оказывается вне области видимости данных. Это создает большое число геморроя.

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

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

Если для запила какой-нибудь там сантехники нужна степень доктора наук

Доктора наук - это совершенно обычные люди. Они так же бывают глупы, так же слепы, так же предвзяты. Просто кто-то качает орка до 90-го уровня, а кто-то фармит себе докторское звание.

как на всей этой радости пилить простым и незатейливым девелоперам, без затей?

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

Если у тебя мегамонстр, то логично вынести фичи в библиотеки, чтобы компилировать только их, если API менять не надо и не надо вносить новые фичи. Да и даже если вносить, то собирать только код основной программы + измененной библиотеки.