AN
Но это уже меняется и будет меняться еще сильнее. С# действительно так себе экосистема для науки. Не потому что язык плохой, а потому что там никто особо этим не занимается. Хотя я знаю довольно сильную комьюнити у суперкомпьютерщиков
Size: a a a
2021 June 11
U
А у раста на этом поприще вообще перспектив нет? Лично меня слегка смущает числодробление с GC, но я и не занимался этим не то что всерьёз, даже сколько-нибудь осмысленно.
AN
Я три года выбирал между растом и котлин. И выбрал на мой взгляд правильно. Проблема в Раста в том, что он слишком сложный для не-программистов. GC вообще никак не мешает числодроблению, только помогает. Мешает боксинг, и отсутсвтие ручного SIMD но и то и другое сравительно легко побеждается
AN
Собственно на мой взгляд котлин - это будущее как раз потому, что позволяет делать очень шустрый код, не думая об низкоуровневых вещах
U
О как, один в один такие же мысли по поводу раста в науке
I
Фортран там во все поля. Ибо MPI + CUDA/OpenACC только С, С++ или Фортран. Из этих трёх последний поддерживает векторизацию в языке и встроенные векторные типы, которые гарантированно векторизуются.
AN
Фортран только для очень низкоуровневой числодробилки на суперкомпьютерах. У него есть ниша, но ооочень узкая. В основном софт в науке это все-таки по шкале Елизарова application level.
AN
гарантированную векторизацию завозят сейчас в JVM, но наши тесты показывают, что JDK 11, а тем более грааль очень неплохо делают это автоматом
I
Ну, я бы не сказал, что числодробление на суперкомпьютере - это узкая ниша. Уж точно не по деньгам.
U
У нас в универе я видел в основном как прикладную шляпу считали на QT или дельфях. Пофиг, что долго и постоянно крашится тут и там.
AN
Ну да, метеорология. Но это все-таки очень специфичная штука. И реаль фортан только там. Если ты хочешь Монте-Карло в частицах, то оно уже ушло почти все с фотрана ибо очеь сложно писать и поодерживать
AN
Именно. И большинство научного софта такое. Перформанс нужен не очень много где. Он должен быть не совсем убитый ка в питоне, но в целом поддерживаемость важнее.
I
Не, под гарантированной векторизацией я имею в виду A = B + C, где все переменные вектора, то компилятор гарантированно векторизует операцию. В то время как в других языках надо либо молиться, что компилятор достаточно умный, чтобы цикл векторизовать, либо ручками векторизовывать с помощью интринсиков.
I
А то, что фортран легко интеропится с сями, делает его очень удобным для интеграции с другими языками (ибо с сями всё интеропится).
AN
Ты пропозалы в JVM смотрел? это завозят. Но меня вполне усраивает, как работает автоматика. В узких местах можно сишные вставки делать. Там еще панаму добавляют, чтобы это проще. Вот только что был доклад по джулии, там все это куда проще, там проще FFI и она заточена под численные штуки, но JIT на LLVM, опциональная типизация, использование гитхаба как репозитория....
VS
... а для перформанса у пользователей есть компиляторщики, профилирование и подбор опций:)
I
Я много пропоузалов видел. Я не знаю, какие пропоузалы ты имеешь в виду без ссылки на эти самые пропоузалы.
AN
Это не отменяет того, что на нем убьъешься писать application level. А он в основном и пишется. Либы хоть на фортране, хоть на си, пофигу. Главное чтобы не на С++ (нулевой интероп).
AN
это уже даже не пропозал