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

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

а как же руст? :(

низкая производительность по сравнению с плюсами

чем угодно это чем?

Хотя бы тем, что компилируется и не имеет GIL

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

Сомневаюсь. Есть просто огромная куча языков, которая например тупо не поддерживает аллокацию объектов на стеке. Уже неплохой такой удар по производительности.

а как же руст? :( (2)

ну ладно пишут, но еще не дописали

Я вот в универе писал одну программу на крестах. Как раз по части числодробления. Так в ней даже между debug и release режимом компиляции была колоссальная разница в производительности.

И не сказать, чтобы я там использовал хитрые оптимизации.

Хотя бы тем, что компилируется и не имеет GIL

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

Сомневаюсь. Есть просто огромная куча языков, которая например тупо не поддерживает аллокацию объектов на стеке. Уже неплохой такой удар по производительности.

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

так что сочетание - скрипт + низвоуровневый язык для скорости - это чисто C или плюсовая специфика, с другими языками скрипт и не нужен

Ну вот как раз C# - это один из тех редких языков, который фактически поддерживает аллокацию на стеке.

Да, но я не уверен, что именно из-за этой фичи прототип выигрывал.

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

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

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

Value-типы

То есть плотность хранения данных выше, указателей меньше, меньше кеш-промахов.

Value-типы

Ну да.

Да, подозреваю, как раз кеш-промахи и были самой главной проблемой того плюсового кода

Да, подозреваю, как раз кеш-промахи и были самой главной проблемой того плюсового кода

Вот это странно на самом деле.

Чем это вообще может быть обусловленно?

Там было слишком много ООП, которое дробило структуры данных и коллекции :(

Но наверняка сказать не могу, так как если бы знал, поучаствовал бы в оптимизации

Странно весьма, тогда почему на шарпе было лучше? Короче, мало инфы доступно.

потому что такой код с кучей объектов и будет быстрее на языке с ГЦ

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

Значит походу хреново C++ код написали.

Отличия C#-прототипа от С++ кода все же радикальные. А прототип оказался быстрее на несколько процентов в среднем, но стабильно. Просто над прототипом не работали, а над плюсовым кодом - работали

Во во.

не так как у языка где нет каких-то разновидностей анбоксинга, конечно

Или у них была куча памяти и аллокаций и GC редко запускался.

Тогда может быть выйгрышь за счёт быстроты аллокаций при наличии GC.

Хм, а в плюсах есть инструменты профилирования попадания данных в кеш?

ну, в случаях когда "гипотеза поколений" работает

а в некоем сферовакуумном ООП коде она вполне работает

ну хоть что-то с ООП нормально работает

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

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

Фортран, через С-интерфейс :))

Фортран, через С-интерфейс :))

Ну это такое. Что угодно - это компилируемый язык без GC?

Ну что вы пристали. Выберите себе язык, вон их сколько

для числодробилок (и машлёрна в том числе) ещё ничего лучше плюсов и не придумали

А как же Python + 100500 обёрток для всех на свете либ?

ну, в случаях когда "гипотеза поколений" работает

Не, я вообще про то, что аллокация памяти при наличии сборщика мусора может выполняться быстрее, чем без него. А гипотеза поколений может как раз покрыта объектами на стеке. Правда у языков типа C# может быть escape analysis, который тоже хотя бы частично может разгрузить GC. Плюс дотнет в отличии от крестов может запросто делать оптимизации во время выполнения.

Фортран, через С-интерфейс :))

ну фортран да, действительно можно:) я думал ты джаву скажешь, хотел уже похоливарить

По поводу Java холиварить скучно :(

Да и по поводу Питона тоже.

А как же Python + 100500 обёрток для всех на свете либ?

либы то всё равно на плюсах

На фортране же

О, кстати, зачем далеко ходить за примерами не таких уж быстрых плюсов? Все олимпиадники знают, что в плюсах не нужно считывать чиселки при помощи потоков, они тормозят. И все делают scanf("%d", &x). Или построчно файл считать. Плюсовая версия значительно тормозней сишной.

На фортране же

ну уж лучше на плюсах тогда, чем на фортране

Помню лет 10 назад можно было на астроотделении матмеха спбгу подработать переписывая числодробительные либы с фортрана на плюсы

Разница небольшая

@A64m_qb0 Про производительность руста:

У нас в JetBrains эксперимент проводили - переписали библиотеку miniz с Си на Rust (ну не С++, а Си, окей). miniz - это сейчас типа самая убероптимизированная inflate/deflate либа, быстрее zlib. Соотв. inflate/deflate - это чистая числодробилка. Есть массив байт на входе, нужно получить другой массив байт на выходе. Только алгоритм реализуй. Ну эта "убероптимизированность" miniz выражается в т.ч. в экстремально нечитаемом коде, где все состоит из макросов со всякими нелокальными goto и прочим. Полное адище. На Rust переписыали буквально по одной функции - Rust с Си превосходно линкуется. Т.е. БУКВАЛЬНО по одной функции переписывали, линковали и прогоняли тесты. Т.е. один в один вся реализация и структура программы сохранены остались. Как переписано было все, уже начали рефакторить. Короче получился очень красивый и читаемый код, просто ни в какое сравнение с оригиналом. Кроме того, блягодаря расту получаем статически гарантируемый type/memory safety. А дальше уже стали ЕГО ОПТИМИЗИРОВАТЬ ЕЩЕ. Потому что код читаемый, понятно что как работает и зачем нужно - можно оптимизивароть. А когда у тебя все на макросах с goto и небезопасно - там хуй что поймешь и боишься что-то трогать. В итоге у нас на 10-20% быстрее оригинала по разным бенчам. ДА, НА РАСТЕ БЫСТРЕЕ ЧЕМ НА СИ. А секрет прост - раст не меньше чем Си дает контроля за тем, какой там код будет сгенерен. Ты пишешь код, и понимаешь, что у тебя в ассемблере будет в этом месте. При этом type/memory/thread safety и вообще красивые абстракции.

Ну а теперь надо с Rust на плюсы перегнать обратно

И ещё +10 процентов скорости

Ну а теперь надо с Rust на плюсы перегнать обратно

и снова получить нечитаемый код

"Как тебе такое, Илон Маск"

и снова получить нечитаемый код

С чего бы?

Раст породжает простыни избыточного текста, точно так же, как си

сам порождает?

С чего бы?

Разные возможности для построения абстракций. Тайпклассы и нормальный параметрический полиморфизм(правда без HKT) vs ООП и template hell

Плюс не факт что раст, написанный сейчас, скомпилится через 20 лет. Или я ошибаюсь?

Плюс не факт что раст, написанный сейчас, скомпилится через 20 лет. Или я ошибаюсь?

Э П О Х И П О Х И

Разные возможности для построения абстракций. Тайпклассы и нормальный параметрический полиморфизм(правда без HKT) vs ООП и template hell

Ну вот что-то мне подсказывает, что перевод Rust -> C/C++ не приведёт к лишнему бойлерплейту. И, кстати, тайпчекинг УЖЕ сделан в Rust'е, поэтому в C/C++ его уже меньше надо (если буквально переводить). Но вообще, интересно было бы посмотреть код на Rust этой miniz, который нельзя было бы читаемо перевести на C/C++

чатик опять продали?

Не, я вообще про то, что аллокация памяти при наличии сборщика мусора может выполняться быстрее, чем без него. А гипотеза поколений может как раз покрыта объектами на стеке. Правда у языков типа C# может быть escape analysis, который тоже хотя бы частично может разгрузить GC. Плюс дотнет в отличии от крестов может запросто делать оптимизации во время выполнения.

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

ERROR: S client not available

Ну вот что-то мне подсказывает, что перевод Rust -> C/C++ не приведёт к лишнему бойлерплейту. И, кстати, тайпчекинг УЖЕ сделан в Rust'е, поэтому в C/C++ его уже меньше надо (если буквально переводить). Но вообще, интересно было бы посмотреть код на Rust этой miniz, который нельзя было бы читаемо перевести на C/C++

> перевод Rust -> C/C++ не приведёт к лишнему бойлерплейту интересно, что же именно подсказывает?

Ну вот что-то мне подсказывает, что перевод Rust -> C/C++ не приведёт к лишнему бойлерплейту. И, кстати, тайпчекинг УЖЕ сделан в Rust'е, поэтому в C/C++ его уже меньше надо (если буквально переводить). Но вообще, интересно было бы посмотреть код на Rust этой miniz, который нельзя было бы читаемо перевести на C/C++

С руста на C/C++ код один в один переводить не получится, ибо тайпклассы, ленивые итераторы и всё вот это вот

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

Только младшее поколение тоже надо вилкой чистить. А на стеке считай автоматическое очищение.

С руста на C/C++ код один в один переводить не получится, ибо тайпклассы, ленивые итераторы и всё вот это вот

А это всё точно использовалось в miniz?

А это всё точно использовалось в miniz?

хз, но в русте ещё макросы человеческие, они тут https://github.com/alexchandel/miniz-rs/blob/master/src/tdefl.rs только так используются, ну и итераторы тоже

У нас в JetBrains эксперимент проводили - переписали библиотеку miniz с Си на Rust (ну не С++, а Си, окей). miniz - это сейчас типа самая убероптимизированная inflate/deflate либа, быстрее zlib. Соотв. inflate/deflate - это чистая числодробилка. Есть массив байт на входе, нужно получить другой массив байт на выходе. Только алгоритм реализуй. Ну эта "убероптимизированность" miniz выражается в т.ч. в экстремально нечитаемом коде, где все состоит из макросов со всякими нелокальными goto и прочим. Полное адище. На Rust переписыали буквально по одной функции - Rust с Си превосходно линкуется. Т.е. БУКВАЛЬНО по одной функции переписывали, линковали и прогоняли тесты. Т.е. один в один вся реализация и структура программы сохранены остались. Как переписано было все, уже начали рефакторить. Короче получился очень красивый и читаемый код, просто ни в какое сравнение с оригиналом. Кроме того, блягодаря расту получаем статически гарантируемый type/memory safety. А дальше уже стали ЕГО ОПТИМИЗИРОВАТЬ ЕЩЕ. Потому что код читаемый, понятно что как работает и зачем нужно - можно оптимизивароть. А когда у тебя все на макросах с goto и небезопасно - там хуй что поймешь и боишься что-то трогать. В итоге у нас на 10-20% быстрее оригинала по разным бенчам. ДА, НА РАСТЕ БЫСТРЕЕ ЧЕМ НА СИ. А секрет прост - раст не меньше чем Си дает контроля за тем, какой там код будет сгенерен. Ты пишешь код, и понимаешь, что у тебя в ассемблере будет в этом месте. При этом type/memory/thread safety и вообще красивые абстракции.

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

Только младшее поколение тоже надо вилкой чистить. А на стеке считай автоматическое очищение.

не надо, в том и дело, гц же не читстит ничего а переносит живое - если живого почти нет, то и работы нет

не надо, в том и дело, гц же не читстит ничего а переносит живое - если живого почти нет, то и работы нет

хм

все адище с гц от массового выживания

Кстати, давно мучает вопрос. А почему не сделают в Haskell отключение GC на время? Вот я хочу выполнить какую-то операцию (в IO), делаю turnoffGC, потом быстренько делаю её, а потом снова turnonGC. Если памяти не хватит -- ну это мои проблемы, готов на это пойти.

Можно как-то это сделать?

в CLR, напрмиер это даже сделано

CLR ?

Что это?

.net

А

Ну а в Haskell?

в хаскеле это до недавнего времени был нереалистичный сценарий, вседь все адово аллоцирует

А... А сейчас как?

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

т.е. все рассчитывалось на то что постоянно адовые аллокации

теперь может и добавят такую фичу, но не факт, просто некому такими вещами заниматься

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

в русте кстати есть возможности писать производительный код, но llvm генерит довольно отвратительный asm.

Отвратительность его в чем?

Читается плохо и не самый эффективный?

там емнип проблемы с определением алиазинга, и потому ллвм плохо оптимизирует

алиасинг да. руст мог бы местами лушче детектить и аннотировать. но и С llvm генерит не очень

обсобенно с битами и шифтами

до GCC ему далеко

LLVM компилит в свой язык, поэтому

Плата за портабельность