После 3 бета-версий и 3-х кандидатов на выпуск официально выпущена Julia 1.10 . Это высокопроизводительный язык общего назначения, популярный в научных вычислениях и численном анализе.
Некоторые особенности новой версии заключаются в следующем:
-
Новый парсер, написанный на Julia
Замените предыдущий парсер по умолчанию, написанный на Scheme, новым синтаксическим анализатором, написанным на Julia, под названием JuliaSyntax.jl . Это изменение вносит несколько улучшений: улучшенную производительность синтаксического анализа, подробные сообщения о синтаксических ошибках, расширенное сопоставление исходного кода.
-
Улучшение времени загрузки пакетов
Эта работа в основном была выполнена путем анализа и улучшения времени загрузки OmniPackage.jl , искусственного «мега-пакета», единственная цель которого — использовать и загружать большое количество зависимостей. В общей сложности OmniPackage.jl загружает около 650 пакетов, многие из которых очень велики.
# Julia 1.9:
48.041773 seconds (102.17 M allocations: 6.522 GiB, 5.82% gc time, 1.21% compilation time: 86% of which was recompilation)
# Julia 1.10:
19.125309 seconds (30.38 M allocations: 2.011 GiB, 11.54% gc time, 10.38% compilation time: 61% of which was recompilation)-
Улучшения в рендеринге трассировки стека.
Благодаря улучшениям в Julia 1.10 трассировки стека стали более краткими:
Stacktrace: [1] error() @ Base ./error.jl:44 [2] f(g::Function, a::Int64; kw::@Kwargs{}) @ Main ./REPL[1]:1 [3] f(a::Int64) @ Main ./REPL[2]:1 [4] top-level scope @ REPL[3]:1Это обновление приводит к тому, что трассировки стека становятся короче и легче читаются.
-
Параллельная сборка мусора
В версии 1.10 фаза маркировки сборщика мусора (GC) была распараллелена и появилась возможность запускать части фазы очистки одновременно с потоком приложения. Это значительно ускоряет время сборки мусора для тяжелых рабочих нагрузок, распределенных по нескольким потокам.
Многопоточный сборщик мусора можно включить с помощью параметра командной строки --gcthreads=M, который определяет количество потоков, используемых на этапе маркировки сборщика мусора. Вышеупомянутое параллельное сканирование страниц также можно включить через --gcthreads=M,1, что означает, что во время фазы маркировки GC будут использоваться M потоков, а один поток GC отвечает за выполнение части фазы сканирования одновременно с приложением.
По умолчанию количество потоков GC установлено равным половине количества вычислительных потоков (--threads).
-
Интеграция аналитики Tracy и Intel VTune ITTAPI
-
Обновление до LLVM 15
Версия Julia 1.10 использует LLVM 15. Это приносит новые процессоры и в целом модернизированные обновленные профили. Особо следует отметить миграцию нового менеджера проходов, который, как ожидается, улучшит время компиляции. В LLVM 15 улучшена поддержка Float16 на x86.
-
Улучшения стабильности Linux AArch64
После обновления до LLVM 15 JITLink можно использовать на процессоре Linux aarch64. Этот компоновщик был первоначально представлен в Julia v1.8 и доступен только на Apple Silicon (процессор aarch64 в macOS), где он устраняет частую проблему с ошибкой сегментации, затрагивающую Julia на этой платформе. Однако из-за ошибки в диспетчере памяти LLVM некритические рабочие нагрузки могут создавать слишком много карт памяти (mmap), что превышает верхний предел разрешенных сопоставлений. Если вы столкнулись с этой проблемой, вы можете прочитать документацию о том, как изменить mmapлимит .
-
Параллельная генерация собственного кода для образов системы и пакетов.
Предварительная компиляция (AOT) ускоряется за счет выявления параллелизма на этапе компиляции LLVM. Теперь вместо компиляции одного большого монолитного модуля компиляции компиляция разбивается на несколько более мелких частей. Такой многопоточный подход ускоряет компиляцию образов системы и образов больших пакетов, тем самым сокращая время их предварительной компиляции.
Степень параллелизма можно контролировать с помощью переменной среды JULIA_IMAGE_THREADS=n. Кроме того, из-за ограничений собственных двоичных файлов COFF для Windows многопоточность отключается при компиляции больших изображений в Windows.
-
Избегайте параллельной предварительной компиляции во время гонок.
В версии 1.10 представлен механизм блокировки «pidfile» (файла идентификатора процесса), который гарантирует, что только один процесс Julia может предварительно скомпилировать данный файл кэша, который устанавливается для конкретного Julia во время процесса предварительной компиляции.
Такая схема выгодна как локальным пользователям, которые могут одновременно запускать несколько процессов, так и пользователям высокопроизводительных вычислений, которые могут запускать сотни рабочих процессов в одном общем репозитории.
-
Параллельная прекомпиляция при использовании
Хотя Pkg будет автоматически прекомпилировать зависимости параллельно после установки, предварительная компиляция во время использования/импорта ранее была последовательной, предварительно компилируя по одному пакету зависимостей за раз.
Когда пользователь разрабатывает пакет, он может оказаться предварительно скомпилированным во время загрузки, и процесс последовательной предварительной компиляции может быть особенно медленным, если изменения кода в разработанном пакете находятся глубоко в дереве зависимостей загружаемого пакета.
В версии 1.10 представлена параллельная предварительная компиляция во время загрузки, чтобы выявить такие случаи и ускорить предварительную компиляцию.
Более подробную информацию можно найти в официальном объявлении .