Источник.
Выпущена новая версия языка программирования Julia 1.11, который сочетает высокую производительность с гибкостью динамической типизации, а также предлагает встроенные средства для параллельного программирования. Синтаксис языка схож с MATLAB, включает элементы Ruby и Lisp, а работа со строками напоминает Perl. Проект распространяется под лицензией MIT.В общем, хороший и нужный ЯП, о котором сегодня и поговорим. Подробности – под катом.
Немного истории
Язык программирования Julia был разработан в 2009 году, и его релиз вышел в 2012 году. Создатели Julia — Джефф Безансон, Стефан Карпински, Вирал Шах и Алан Эдельман. Основной целью разработки было создание языка, который бы сочетал высокую производительность с простотой использования, характерной для таких языков, как Python или R. Они стремились решить проблему, которая часто возникает при научных и численных вычислениях: необходимость писать прототипы на удобных, но медленных языках и затем переписывать их на более производительных, таких как C или Fortran.
Julia получила поддержку многих парадигм программирования, интеграцию с библиотеками C, возможность эффективных численных вычислений, а также встроенные средства для работы с параллельными задачами.
Основные особенности языка
- Высокая производительность: Одной из главных целей Julia является достижение уровня производительности, сравнимого с программами, написанными на C. Компилятор языка, построенный на базе LLVM, генерирует эффективный машинный код для различных целевых платформ.
- Поддержка нескольких парадигм программирования: Julia поддерживает элементы объектно-ориентированного и функционального программирования. Стандартная библиотека включает функции для асинхронного ввода/вывода, управления процессами, логирования, профилирования и управления пакетами.
- Динамическая типизация: Как и в большинстве скриптовых языков, для переменных в Julia не требуется явное указание типов. Поддерживается интерактивный режим работы.
- Опциональная строгая типизация: При необходимости можно явно указывать типы переменных и аргументов функций для улучшения производительности и удобства отладки.
- Оптимизированный синтаксис для численных вычислений: Julia идеально подходит для научных и математических расчетов, машинного обучения и визуализации данных, благодаря широкому набору встроенных типов данных и поддержке параллельных вычислений.
- Прямой вызов библиотек на языке C: Julia позволяет напрямую вызывать функции из библиотек на C без промежуточных прослоек, что повышает гибкость и производительность.
Основные новшества в версии 1.11
Новые возможности языка:
- Тип Memory: Введен новый тип данных Memory, который является низкоуровневой альтернативой Array. Он требует меньше ресурсов и имеет более быстрый конструктор, что делает его предпочтительным для задач, где не требуется полный функционал Array, например, для работы с многомерными массивами. Внутренняя реализация методов Array теперь основана на Memory, что привело к значительному ускорению некоторых операций, таких как push.
- Ключевое слово public: Введено новое ключевое слово public, которое используется для маркировки идентификаторов, являющихся частью внешнего интерфейса. В отличие от export, такие идентификаторы не импортируются автоматически в контексте модуля при использовании using в других модулях.
help?> GC.in_finalizer
│ Warning
│
│ The following bindings may be internal; they may change or be removed in future versions:
│
│ • Base.GC.in_finalizer
GC.in_finalizer()::Bool- Пакет ScopedValue: Появился новый пакет для поддержки динамической области видимости при параллельном программировании с использованием Threads/tasks.
- Файлы Manifest.toml: Теперь поддерживается переименование файлов Manifest.toml в формат Manifest-v{major}.{minor}.toml, что позволяет использовать конкретные версии Julia. Например, файл Manifest-v1.11.toml будет ассоциирован с версией 1.11, а Manifest.toml — с другими версиями.
- Unicode 15.1: В новой версии добавлена поддержка стандарта Unicode 15.1, что расширяет возможности работы с текстом на разных языках.
Изменения в языке:
- Прекомпиляция и обработка atexit: Во время прекомпиляции теперь запускается обработчик atexit, что позволяет безопасно завершать фоновое выполнение задач и освобождать ресурсы перед завершением программы.
- Файлы покрытия кода: Во время прекомпиляции файлы покрытия кода и выделения памяти больше не создаются. Кэши pkgimage теперь используются для пакетов, которые не отслеживаются, что ускоряет тестирование и повышает производительность.
- Обработка переменной JULIA_DEPOT_PATH: Теперь при указании одного пути в переменной JULIA_DEPOT_PATH, только он будет вставлен в значение переменной. Если путь заканчивается символом ":", добавляются также системные пути.
- Кэши прекомпиляции: Файлы кэша прекомпиляции теперь можно перемещать, а их актуальность проверяется с помощью хешей содержимого исходных файлов, а не через дату изменения файлов.
Улучшения многопоточности:
- Новый режим планировщика :greedy: В макросе Threads.@threads добавлен новый режим планировщика :greedy, который оптимизирован для задач с неравномерной вычислительной нагрузкой.
- Новая структура Base.Lockable: Добавлена новая структура Base.Lockable, которая упрощает код при параллельном доступе к элементам составных типов, снижая вероятность ошибок.
Изменения в компиляции и среде выполнения:
- Сборщик мусора: Обновлена работа сборщика мусора, что позволяет обрабатывать страницы памяти целиком, а не отдельные объекты, что улучшает производительность.
- Поддержка аннотаций: Добавлена возможность аннотирования кода с помощью макроса Base.@assume_effects, что расширяет возможности управления побочными эффектами в коде.
Новые параметры командной строки:
- Точка входа Main.main(args): Теперь строго определена точка входа Main.main(args) для выполнения скриптов через командную строку. Это унифицирует поведение кода при его компиляции и запуске.
- Аргумент --project=@script: Теперь поддерживается аргумент --project=@script для указания пути к файлу Project.toml относительно запущенного скрипта.
Новые функции библиотеки:
- Типы для аннотированных строк: Добавлены новые типы для работы с аннотированным текстом, такие как AnnotatedString, AnnotatedChar и AnnotatedIOBuffer. Эти типы позволяют добавлять аннотации к строкам и символам, что полезно для визуализации данных с учётом стиля.
- Метод Sys.username(): Теперь можно получить имя текущего пользователя с помощью метода Sys.username(). Добавлены также методы для проверки прав доступа — Sys.isreadable() и Sys.iswritable().
- Новые методы для строк и коллекций: Метод eachrsplit() теперь позволяет разбивать строку с конца, а функция logrange() создаёт логарифмические последовательности. Метод allequal() проверяет равенство всех элементов коллекции, а allunique() проверяет уникальность.
Изменения в базовых библиотеках:
- Метод write(::IO, ::AbstractArray): Теперь запись массива в поток происходит рекурсивно для каждого элемента, что улучшает совместимость с методом read!.
- Новая стандартная библиотека StyledStrings: Введена библиотека для стилизованного отображения текста. Использование макроса @styled_str позволяет создавать аннотированные строки с различными стилями, такими как цвет и декорации.
Устаревшие и удаленные методы:
- Удаление методов Base.map, Iterators.map и foreach с одним аргументом: Эти методы больше не поддерживаются и были удалены.
Внешние зависимости:
- Обновление libuv: В новой версии Julia библиотека libuv обновлена с 1.44.2 до 1.48.0, что улучшает работу с системными ресурсами.
- Замена tput на terminfo: Метод tput для проверки возможностей терминала больше не используется, его заменили на средства анализа terminfo, реализованные полностью на языке Julia.
Улучшения инструментов:
- Автоматическая проверка типов в CI: Теперь CI автоматически проверяет типы в запросах на слияние, что повышает стабильность кода.
Julia 1.11 привнесла множество изменений, которые улучшили производительность, параллельную обработку, работу с памятью и расширили функциональные возможности для научных и высокопроизводительных вычислений. С полным списком можно ознакомиться вот здесь.
Комментарии (22)
mbait
13.10.2024 12:13Так и не понял, чем Julia лучше Python или Matlab. Первый проще и (пока ещё) не имеет вырвиглазного синтаксиса, который приходится каждый раз вспоминать. У второго есть невероятное количество встроенных моделей и пакетов-расширений. Julia в своём стремлении охватить как можно больше парадигм и ниш похож на С++.
unreal_undead2
13.10.2024 12:13Если не получается в основном вычислительном ядре запользовать готовые библиотеки или высокоуровневые примитивы, производительность кода на Python/Matlab будет так себе.
vadimfry
13.10.2024 12:13Никто и не утверждает что голый питон производителен. Но я не могу найти ситуации, когда для решения научной задачи ты не можешь установить numpy, numba, taichi и подобные, которые закрывают все возможные потребности, с которыми можно столкнуться на практике, и не писать при этом в 5 раз больше кода. Тем более, что реализации популярных алгоритмов на подобных библиотеках часто находятся в общем доступе, и всегда можно залезть под капот.
unreal_undead2
13.10.2024 12:13Одно время работал с товарищами, моделирующими термояд - там были голые фортрановские коды. Естественно, об оптимизированных вариантах BLAS и прочих библиотеках люди были в курсе - не подходило.
vadimfry
13.10.2024 12:13Знаю про такое. У нас квантмех моделируют. Говорят, что видеокарты не подходят, чтобы ускорять расчеты, ввиду ограничений точности возможных использований типов переменных, а также нужно по 200+ гигов оперативы. Пишут на голом фортране. И используют древние супер компы на зеончиках. Но надо понимать, что там костыльная база 30-тилетней давности, которую никто на что-то современное переписывать не будет. Тем более, что там и работают над этим уже по сути деды. А я начал на питоне и уходить с него не увидел причин, т.к. чаще всего и float32 хватает, чтобы приближенно плазму в тлеющем разряде посчитать.
unreal_undead2
13.10.2024 12:13Если хватает numpy и т.п. - почему бы и нет. Кстати, что в питоне сейчас принято использовать для распараллеливания на кластере?
vadimfry
13.10.2024 12:13Я использую taichi. Позволяет параллелить на процессоре или видеокарте используя cuda или vulkan. Пишешь на питоноподомном синтаксисе, а код преобразуется в плюсовый, а потом в машинный. Сильно экономит время и объем кода. Также можно встроенными способами объединять несколько систем в один кластер. Правда я это не использую, ибо никто мне много компов не выделил. Дали 4070 и на том спасибо. Еще популярен pytorch, но он скорее для нейросеток.
unreal_undead2
13.10.2024 12:13Я именно про запуск счётного кода (не нейронки) на сотне-другой компов в кластере.
vadimfry
13.10.2024 12:13Я знаю лишь о том, что сам использую. А так вариантов довольно много и кому не лень пишут такие библиотеки и фреймворки, поэтому разработчики используют на свое усмотрение. А так то, что для нейронок можно использовать и для обычных вычислений, просто такие инструменты сильнее заточены под работу с числами точностью меньше float32. Все равно чаще всего они опираются на cuda под капотом и доступен весь его функционал.
unreal_undead2
13.10.2024 12:13то, что для нейронок можно использовать и для обычных вычислений
Там же вполне конкретные алгоритмы, фреймворк на входе по идее просто структуру сетки берёт, а не произвольный код. Но я к тому, что реально тяжёлые вычисления на одну ноду просто не влезут (скажем, large size в SpecHPC требует до 14.5Tb оперативки), надо как то разбивать данные, обмениваться между нодами и т.д.
vadimfry
13.10.2024 12:13Я понимаю о чем вы, но мне с такими масштабами работать не приходилось. Максимум под 100 гиг памяти. Да и требований запускать ракеты с дурной точностью тоже. Поэтому про такое сказать ничего не могу. В научной среде нормальное железо толком не выделяют, да и большинство ученых, которых я знаю программирование вообще стороной обходят, либо используют готовый софт, что печально, ибо неоткуда брать опыт.
AuToMaton
И тут, раз уж мы опустились на этот уровень, как мне кажется, непременно нужно добавить пояснение - Julia не предназначена для создания приложений в ещё большей степени чем Python. Но в меньшей чем Racket. Если этого не сделать, то можно спровоцировать переход на Julia с, скажем, JavaScript, вот ведь какой прекрасный язык в статье описан и всё правда, чем оказать медвежью услугу.
randomsimplenumber
Если кто-то занимался научными расчетами на js, то перейти на Julia не выглядит плохой идеей ;)
AuToMaton
Если именно занимался расчётами - точно не выглядит. А если работал над приложениями для научных расчётов - то скорее выглядит.
Я склонен раскладывать всю околопрограммистскую работу на три кучки - работа над себя, на продажу и на дядю. Раз предоставился дополнительный случай её похвалить, скажу - Julia мне нравится ещё и тем что попадает строго в первую.
unreal_undead2
Julia вроде как изначально задумывалась, чтобы заменить Фортран как язык, на котором пишут всяческие физики/химики для своих нужд.
AuToMaton
Сейчас сказывают малость иначе. Они называют это «решить проблему двух языков» - одного чтобы писать прототип где необходим быстрый цикл изменений, и второго для того чтобы писать эффективный код для собственно расчётов. Текущее состояние дел - проблема двух языков решена, но появилась «проблема полутора языков» - код, полученный в результате быстрого прототипирования, нужно оптимизировать для повышения производительности.
Да, физики и химики конечно, но не только - вообще все кто использует комп для себя. Сейчас специалисты по данным и машинному обучению подтягиваются.
unreal_undead2
В любом случае в первую очередь специалисты в целевой области, а не чистые девелоперы.
AuToMaton
Именно так, что я и пытался объяснить. «Специалисты в целевой области» хорошо сформулировано.
SquareRootOfZero
В смысле, условному свитчеру может не хватить своих мозгов чтобы проверить, есть ли для Julia транспайлер в JavaScript, компиляция в WebAssembly, или что там ещё щас хотят для "создания приложений" на JavaScript?
AuToMaton
Условному свитчеру может хватить мозгов подобными вещами не заморачиваться. Есть энтузиасты которые работают над приложениями на Julia, но это очень не мейнстрим. Я думаю что транспайлер в JS невозможен в принципе. WebAssembly казалась реализуемой на столько, что её даже обсуждали.
Не предназначена не значит что невозможно. Но на практике значит что на столько криво и ограниченно, что можно и так считать.