Rust для численного счёта возможен?

[StaticZero]

Не знаком с Rust, но я устал уже писать одну и ту же императивную тарабарщину на Си и 24/7 искать там утёкшую память.

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

С другой стороны может оказаться, что он вообще не приспособлен для конкретно задачи долбёжки чисел. Главным образом интересует вопрос производительности по сравнению с каноническими C/Fortran (хотя стоит ошибиться где-то в сишном коде и результат будет быстрый, но абсолютно бесполезный). Легко ли там параллелить? OpenCL можно прикрутить чтобы майнить?

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

[warlock66613]

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

Что касается лёгкости использования сишных функций... Биндинги-то всё равно придётся делать (если кто-то не сделал их уже до вас), просто взять и импортировать заголовочный файл не получится. Так что в этом плане Rust недалеко ушёл от общей массы языков.

[Pphantom]

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

[ipgmvq]

StaticZero в сообщении #1474458 писал(а):

и 24/7 искать там утёкшую память

У меня на Python в scipy при 100% многочасовой параллельной загрузке 2 ядер на i3 (насколько помню численную интеграцию делал scipy.integrate) память утекала, так что вся оперативка заполнялась за несколько часов — приходилось в скрипт дописать проверку количества свободной памяти и при достижении критических значений, завершать скрипт, и автоматически запускать его заново в новом процессе.
Переписал на C (GNU Scientific Library) — всё летает и главное ничего не утекает вообще (ни за часы, ни за дни).
Вызываю функции C из Питона.

Про Rust смотрел на YouTube, но не работал. Желания с C на Rust в плане вычислений переходить не было. Cи настолько простой и компактный язык, интегрированный в системные API Unix-систем, что с ним очень комфортно и предсказуемо.

[StaticZero]

Pphantom в сообщении #1474484 писал(а):

итоговая скорость кода все же поменьше

А на чём просел, не говорили?

[Pphantom]

StaticZero в сообщении #1474674 писал(а):

А на чём просел, не говорили?

Нет. Кажется, это скорее общее впечатление, я не уверен, что детальным профилированием занимались.

[StaticZero]

Pphantom в сообщении #1474695 писал(а):

Нет. Кажется, это скорее общее впечатление, я не уверен, что детальным профилированием занимались.

Спасибо. Я всё-таки решился. Может быть, на форум чего напишу по поводу приложения к одной численной задачке; там уже есть код на C, было бы интересно сравнить. Пока всё нравится.

[Pphantom]

StaticZero в сообщении #1474706 писал(а):

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

Давайте, это было бы интересно.

[Snegovik]

Просто интересно, современные версии фортрана не рассматривали? Как числодробилка хороший выбор.

[ipgmvq]

StaticZero в сообщении #1474706 писал(а):

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

Будет очень интересно!

Snegovik
А что Вы цените в Фортране больше всего, если сравнивать с обычным C, в плане числодробления?
я знаю там комплексные числа вроде как являются стандартным типом данных. Есть ли какие-то ещё фундаментальные преимущества?
Но я видел также выступление Phillip Carter, Managing Director по технологиям Morgan Stanley (там, где много лет работает создатель C++ Bjarne Stroustrup), где он в 2014 году рассказывает про то, как переключал Morgan Stanley с Фортрана на C и C++ в 1994 году. Я слушал, что с тех пор Фортран обновили. Но тем не менее.

[Pphantom]

ipgmvq в сообщении #1474969 писал(а):

Есть ли какие-то ещё фундаментальные преимущества?

В общем-то на форуме это несколько раз обсуждалось.

Развитая система типов, многочисленные векторные операции, естественным образом формулируемые алгоритмы... в общем, для получения аналогичного по производительности кода от программиста требуется на порядки меньшая квалификация.

[ipgmvq]

Pphantom
Спасибо!
Да, когда работа с векторами удобна, это очень здОрово. За эту простоту я очень люблю язык R.

[Pphantom]

Только скорость у R... ну понятно. Фортран все это успешно сочетает с производительностью кода, за которой на C еще постараться угнаться надо (а на всем остальном даже при старании проблематично).

[ipgmvq]

Pphantom

Pphantom в сообщении #1474976 писал(а):

Только скорость у R... ну понятно.

Сущая истина. Но признаться, и задач с матрицами у меня ресурсоемких не было, так чтобы заметить медленность R именно в этом use case. Насколько я понимаю, при работе с большими матрицами лимитирующим фактором чаще является не ЦП, а просто размер ОЗУ, т.к. они и результаты вычислений в него одновременно не помещаются.

[StaticZero]

Snegovik в сообщении #1474949 писал(а):

Просто интересно, современные версии фортрана не рассматривали? Как числодробилка хороший выбор.

Ну это классический выбор, так скажем (даже более классический, наверное, чем Си).

Но в том дело, что я, если можно так сказать, устал от этой классики, где постоянно нужно что-то оборачивать в проверки безопасности, постоянно где-то надо за указателями следить (ох, и достало меня restrictами всё обмазывать, ёлки-палки!), итоговый код тяжело поддерживать и т. д., и т. п.

Это не профессиональное суждение, конечно. Очень легко может оказаться так, что я как программист полностью негоден, потому что испытываю такие эмоции, а не с языками что-то не так. Это замечательные языки (я имею в виду "большую тройку", C, C++, Fortran), много десятилетий подряд показывают успех. Но я хочу чего-то более высокоуровневого. Rust должен позволить мне не следить за указателями, за которыми следить не обязательно, он из коробки restrict-based, как я понял, ну и так далее. Вопрос, как много я заплачу за это в плане производительности.

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