Комментарии 38
Выпущена новая версия языка программирования Julia 1.11, который сочетает высокую производительность…
И тут, раз уж мы опустились на этот уровень, как мне кажется, непременно нужно добавить пояснение - Julia не предназначена для создания приложений в ещё большей степени чем Python. Но в меньшей чем Racket. Если этого не сделать, то можно спровоцировать переход на Julia с, скажем, JavaScript, вот ведь какой прекрасный язык в статье описан и всё правда, чем оказать медвежью услугу.
Если кто-то занимался научными расчетами на js, то перейти на Julia не выглядит плохой идеей ;)
Если именно занимался расчётами - точно не выглядит. А если работал над приложениями для научных расчётов - то скорее выглядит.
Я склонен раскладывать всю околопрограммистскую работу на три кучки - работа над себя, на продажу и на дядю. Раз предоставился дополнительный случай её похвалить, скажу - Julia мне нравится ещё и тем что попадает строго в первую.
Julia вроде как изначально задумывалась, чтобы заменить Фортран как язык, на котором пишут всяческие физики/химики для своих нужд.
Сейчас сказывают малость иначе. Они называют это «решить проблему двух языков» - одного чтобы писать прототип где необходим быстрый цикл изменений, и второго для того чтобы писать эффективный код для собственно расчётов. Текущее состояние дел - проблема двух языков решена, но появилась «проблема полутора языков» - код, полученный в результате быстрого прототипирования, нужно оптимизировать для повышения производительности.
Да, физики и химики конечно, но не только - вообще все кто использует комп для себя. Сейчас специалисты по данным и машинному обучению подтягиваются.
В смысле, условному свитчеру может не хватить своих мозгов чтобы проверить, есть ли для Julia транспайлер в JavaScript, компиляция в WebAssembly, или что там ещё щас хотят для "создания приложений" на JavaScript?
Условному свитчеру может хватить мозгов подобными вещами не заморачиваться. Есть энтузиасты которые работают над приложениями на Julia, но это очень не мейнстрим. Я думаю что транспайлер в JS невозможен в принципе. WebAssembly казалась реализуемой на столько, что её даже обсуждали.
Не предназначена не значит что невозможно. Но на практике значит что на столько криво и ограниченно, что можно и так считать.
а чего на кдпв неправильное название?
Так и не понял, чем Julia лучше Python или Matlab. Первый проще и (пока ещё) не имеет вырвиглазного синтаксиса, который приходится каждый раз вспоминать. У второго есть невероятное количество встроенных моделей и пакетов-расширений. Julia в своём стремлении охватить как можно больше парадигм и ниш похож на С++.
Если не получается в основном вычислительном ядре запользовать готовые библиотеки или высокоуровневые примитивы, производительность кода на Python/Matlab будет так себе.
Никто и не утверждает что голый питон производителен. Но я не могу найти ситуации, когда для решения научной задачи ты не можешь установить numpy, numba, taichi и подобные, которые закрывают все возможные потребности, с которыми можно столкнуться на практике, и не писать при этом в 5 раз больше кода. Тем более, что реализации популярных алгоритмов на подобных библиотеках часто находятся в общем доступе, и всегда можно залезть под капот.
Одно время работал с товарищами, моделирующими термояд - там были голые фортрановские коды. Естественно, об оптимизированных вариантах BLAS и прочих библиотеках люди были в курсе - не подходило.
Знаю про такое. У нас квантмех моделируют. Говорят, что видеокарты не подходят, чтобы ускорять расчеты, ввиду ограничений точности возможных использований типов переменных, а также нужно по 200+ гигов оперативы. Пишут на голом фортране. И используют древние супер компы на зеончиках. Но надо понимать, что там костыльная база 30-тилетней давности, которую никто на что-то современное переписывать не будет. Тем более, что там и работают над этим уже по сути деды. А я начал на питоне и уходить с него не увидел причин, т.к. чаще всего и float32 хватает, чтобы приближенно плазму в тлеющем разряде посчитать.
Если хватает numpy и т.п. - почему бы и нет. Кстати, что в питоне сейчас принято использовать для распараллеливания на кластере?
Я использую taichi. Позволяет параллелить на процессоре или видеокарте используя cuda или vulkan. Пишешь на питоноподомном синтаксисе, а код преобразуется в плюсовый, а потом в машинный. Сильно экономит время и объем кода. Также можно встроенными способами объединять несколько систем в один кластер. Правда я это не использую, ибо никто мне много компов не выделил. Дали 4070 и на том спасибо. Еще популярен pytorch, но он скорее для нейросеток.
Я именно про запуск счётного кода (не нейронки) на сотне-другой компов в кластере.
Я знаю лишь о том, что сам использую. А так вариантов довольно много и кому не лень пишут такие библиотеки и фреймворки, поэтому разработчики используют на свое усмотрение. А так то, что для нейронок можно использовать и для обычных вычислений, просто такие инструменты сильнее заточены под работу с числами точностью меньше float32. Все равно чаще всего они опираются на cuda под капотом и доступен весь его функционал.
то, что для нейронок можно использовать и для обычных вычислений
Там же вполне конкретные алгоритмы, фреймворк на входе по идее просто структуру сетки берёт, а не произвольный код. Но я к тому, что реально тяжёлые вычисления на одну ноду просто не влезут (скажем, large size в SpecHPC требует до 14.5Tb оперативки), надо как то разбивать данные, обмениваться между нодами и т.д.
Я понимаю о чем вы, но мне с такими масштабами работать не приходилось. Максимум под 100 гиг памяти. Да и требований запускать ракеты с дурной точностью тоже. Поэтому про такое сказать ничего не могу. В научной среде нормальное железо толком не выделяют, да и большинство ученых, которых я знаю программирование вообще стороной обходят, либо используют готовый софт, что печально, ибо неоткуда брать опыт.
Как тогда ваши знакомые учёные данные анализируют и визуализируют? Да, обычный учёный это не программист, но код приходится писать почти каждый день.
Представьте себе. Нынче модно использовать готовый софт, доставшийся от предыдущих поколений, и ничего нового не создавать. И в технических сферах чаще всего нет таких данных, чтобы для них подключать программирование, а екселя достаточно, чтобы построить линии тренда. Для написания серьезного софта с серьезным моделированием мало у кого есть соответствующие знания, и их в моей стране толком ни в одном вузе не дают, и работа ведется по более простым путям.
Да, если достаточно запользовать какой нибудь Gromacs или VASP - никаких проблем, можно ничего не писать. Но, скажем, недавно слушал доклад про МГУшный кластер - самописного софта (и проблем с оптимизацией его производительности) там хватает.
У нас область микро-и наноэлектроники. поэтому есть своя специфика, что и как можно делать. Частенько просто экспериментальных данных с их анализом достаточно, чтобы считаться нормальным специалистом. А там где чистые матанщики - без программирования делать нечего.
Обработка экспериментальных данных - особая тема. Но там тоже нормальные мощности могут понадобиться - если эти данные, скажем, с коллайдера приходят ) Лично не работал, но коллеги в CERN в командировки ездили насчёт оптимизации ворклоадов по обработке данных.
Коллайдеры это отдельная песня и всякие реакторы с кучей датчиков. Чаще всего данных кот наплакал, и работать приходится с парой зависимостей или просто конечными результатами, которые еще и измерены со слабой точностью. Я работаю над моделированием магнетронных распылительных систем и из экспериментальных данных у меня только стартовые условия, один-два ВАХ-а и распыленная мишень. И крутись как хочешь. Обрабатывать толком и нечего, только использовать как справочный материал.
Какие то красивые 3D картинки на презентациях видел, но не знаю чем делали, по работе занимался анализом того, как код на CPU бежит.
pyspark. но вообще я десятки терабайт векторов на numpy гонял на map-reduce кластере, blas работает, всё шустро
Если что-то простое, то это, кхм, просто slurm и задачи на сетке или в разные моменты времени.
Матлаб, на мой взгляд, проще питона. В отличие от него, он заточен на анализ данных, а не на потенциальное создание всего на свете, и разрабатывается одной компанией, а не всем миром. Нет импорта модулей, проще и удобнее работа с массивами, компактный и единообразный синтаксис, отличная IDE, очень хорошая документация, ну и построение графиков, в конце-концов, в одну команду. Но платный. Так что современное поколение, приходящее из университетов, почти все питонисты.
Язык программирования Julia 1.11: новый релиз и много возможностей. Что добавили разработчики и что изменилось?