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

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

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

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

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

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

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

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

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

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

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

Value-типы

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

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

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

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

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

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

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

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

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

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

С чего бы?

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

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

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

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

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

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

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

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

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

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

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