Julia 1.13 の主な変更点

Julia 1.13 の主な変更点 2026年9月10日 | Juliaコントリビューターズ Juliaバージョン1.13がリリースされました。このリリースに貢献してくれたすべてのコントリビューターと、プレリリース版でリグレッションや問題を見つけるのを手伝ってくれたすべてのテスターに感謝します。皆様なしでは、このリリースは不可能でした。変更点の全リストはNEWSファイルにありますが、ここではリリースハイライトの一部をより深く掘り下げて概観します。 レイテンシ（TTFX）の改善 REPLの改善 シンタックスハイライト fzfスタイルの履歴検索 Windowsでのブラケットペースト @__FUNCTION__ ハッシュの変更 マーキング中のイメージオブジェクトをスキップすることによるGCの高速化 スケジューラと割り込みの修正 型アノテーションによるイントロスペクション --trace-evalによるトップレベル評価のトレース JuliaC/trimPkg デフォルト圧縮アルゴリズムのgzipからzstdへの変更 パッケージレジストリのマニフェストでの追跡 ソースの再帰的な収集 pkg> add がロード済みのパッケージと同じバージョンを追加しようとする Pkg.test が厳密な境界チェックをデフォルトで有効にしなくなった Juliaup GUI レイテンシ（TTFX）の改善 Ian Butterworth、他多数 Julia 1.13 は、1.12 よりもパッケージのプリコンパイルに約30%少なく、1.10 (LTS) より約10-20%少ない時間を要します（マシンによります）。Time To First X (TTFX)、つまりJuliaの起動から最初の結果を得るまでの時間は、プリコンパイル、ロード、コード実行の3つの主なコストで構成されます。Julia-TTFX-Snippetsでコミュニティから提供されたワークフローの助けを借りて、実際の例でこれらのコストをより体系的に測定し、それらに対してJuliaを最適化し始めました。以下のチャートは、2台のマシンで現在提出されている39のワークフローすべてにおける幾何平均を示しています。プリコンパイルは2回の実行のうち最も速いもの、ロードと実行時間は3回の実行のうち最も速いものです。このモニタリングはJulia自身の開発プロセスの一部にもなっています。新しいTTFX CIジョブは関連するプルリクエストとmasterへの各コミットで実行され、結果はperf.julialang.org/ttfxで追跡されます。その追跡は2026年9月7日に開始されました。それ以前の測定はアドホックでした。Julia 1.13 の起動も 1.12 より約20%高速です。 % hyperfine --warmup 3 --runs 20 -N \ --command-name "julia 1.12" "julia +1.12 --startup-file=no -e ''" \ --command-name "julia 1.13" "julia +1.13 --startup-file=no -e ''" ベンチマーク 1: julia 1.12 時間 (平均 ± σ): 69.1 ms ± 1.0 ms [ユーザー: 50.1 ms, システム: 18.1 ms] 範囲 (最小 … 最大): 68.0 ms … 72.6 ms 20回の実行 ベンチマーク 2: julia 1.13 時間 (平均 ± σ): 56.7 ms ± 0.5 ms [ユーザー: 49.1 ms, システム: 18.9 ms] 範囲 (最小 … 最大): 56.0 ms … 58.1 ms 20回の実行 要約 julia 1.13 は julia 1.12 より 1.22 ± 0.02 倍高速に実行されました。 REPLの改善 シンタックスハイライト Timothy, Kristoffer Carlsson Julia REPL にシンタックスハイライトが追加されました（OhMyREPL.jl のような外部パッケージをロードする必要はありません）。デフォルトでは、カラースキームはかなり控えめですが、簡単にカスタマイズできます（REPL のドキュメントを参照してください）。例として、Monokai カラースキームを使用した同じコードを以下に示します。 新しいfzfスタイルの履歴検索 Timothy 履歴検索（デフォルトで Ctrl-R で入力）が再設計され、コマンドラインのファジーファインダー fzf と同様に機能するようになりました。新しい履歴検索には、とりわけ以下のサポートがあります。 履歴でのファジー検索。 コマンドに使用された REPL モードの表示。 複数の検索結果を選択してプロンプトバッファに入れる機能。 REPL 自体と一致するコードのシンタックスハイライト。 履歴検索を入力して ? をタイプすると、完全なヘルプが表示されます。 Windowsでのブラケットペースト ブラケットペーストにより、ターミナルで実行されているアプリケーションは、テキストが単に入力されたのではなく、貼り付けられたことを知ることができます。これにより、貼り付けられたテキストのより効率的で正確な処理が可能になります。この機能は Linux および macOS では長らく有効でしたが、ついに Windows でも利用可能になりました。具体的な例として、以下のビデオは、Windows でブラケットペーストを有効にする前と後で、約500行の関数を Julia REPL に貼り付けたときの動作を示しています。 有効にする前: 有効にした後: @__FUNCTION__ Miles Cranmer, Jeff Bezanson 既存の @__MODULE__ および @__FILE__ マクロと同様に、新しい @__FUNCTION__ マクロは、匿名関数であっても、最も内側の包含関数を参照します。これはあらゆる種類の関数で機能するはずであり、内部変数 #self# とは異なり、公開 API です。 julia> fact = n -> n <= 1 ? 1 : n * @__FUNCTION__()(n - 1); julia> fact(5) 120 ハッシュの変更 Andy Dienes, Jameson Nash ハッシュ関数が置き換えられました。バイトハッシュアルゴリズムは RapidhashNano になりました。このハッシュは、AbstractString および BigInt、Rational、大きな Real または Integer 値などの多くの数値型でデフォルトで使用されます。また、カスタム型が、サポートされている型（Stringなど）に変換する前に、ジェネリック実装をオプトインすることがはるかに容易になりました。この変更は、MurmurHash3 に基づく既存の実装と比較していくつかの利点を提供します。パフォーマンスが大幅に向上し、ストリーミングハッシュであるため入力長を事前に必要としなくなり、C から純粋な Julia に移行したため可読性と保守性が向上しました。長い文字列でのパフォーマンス向上を実証するために: using BenchmarkTools, Downloads io = IOBuffer() Downloads.download("https://www.gutenberg.org/cache/epub/1080/pg1080.txt", io) s = String(take!(io)) # 1.12 @btime hash($s) 8.555 μs (0 allocations: 0 bytes) 0x5fbd2717019846ea # 1.13 @btime hash($s) 1.742 μs (0 allocations: 0 bytes) 0x718308e795047519 高速フォールバックをオプトインするデモンストレーション: struct MyString <: AbstractString s::String end m = MyString(s) # 1.12 Base.iterate(m::MyString) = iterate(m.s) Base.iterate(m::MyString, i::Integer) = iterate(m.s, i) @btime hash($m) 204.583 μs (21 allocations: 107.02 KiB) 0x5fbd2717019846ea # 1.13 Base.codeunit(m::MyString) = codeunit(m.s) Base.codeunits(m::MyString) = codeunits(m.s) @btime hash($m) 1.750 μs (0 allocations: 0 bytes) 0x718308e795047519 小さな固定幅データのハッシュも変更されました。最終的な混合ステップは、注意深く調整された定数を持つ単一ラウンドのXMX構成になり、混合ステップはハッシュ呼び出しを合成する際に適切にアバランシングするようになりました。以前は混合ステップは常に各合成深度で線形関数に単純化されていました。混合ステップのこの変更はデータ依存性（したがってパフォーマンスが低下する可能性）を導入しますが、小さいから中程度のサイズではAbstractArrayのハッシュアルゴリズムが部分的に展開され、複数のハッシュアキュムレータを並列に維持するため、ほとんどの長さで大幅に高速になります。 いくつかの重要なリマインダー: ハッシュは非暗号化のままです。また、デフォルトのシードが変更されました。カスタムハッシュメソッドは、常にシードを引数として受け取る必要があります（例: hash(x::MyType, h::UInt)）し、デフォルト値を提供しないでください（例: hash(x::MyType, h::UInt=0)）、なぜなら正しいシードは呼び出し元によって決定されるからです。 マーキング中のイメージオブジェクトをスキップすることによるGCの高速化 Cody Tapscott すべてのJuliaセッションは、システムイメージからロードされた多数のオブジェクトで開始され、ロードされる各パッケージはさらに多くのオブジェクト（メソッドテーブル、型情報、コンパイル済みコード、定数など）を持つパッケージイメージをもたらします。これらのオブジェクトは決して解放されず、めったに変更されませんが、これまでフルガベージコレクションは、ヒープ上の他のすべてのオブジェクトと同様に、それらを到達可能としてマークするためにそれらすべてをウォークしていました。少数の大きなパッケージがロードされたセッションでは、これはフルコレクションの主要なコストになる可能性があります。Julia 1.13 では、sysimage およびパッケージイメージ内のオブジェクトは永続的にマークされたものとしてロードされ、マークフェーズはそれらに入ることはありません。イメージオブジェクトに対する少数の変更（たとえば、既存の関数にメソッドが追加された場合など）は個別に追跡されるため、それらが指す新しいオブジェクトは引き続き生存します。その効果は、フルコレクションのコストが、ヒープ上のオブジェクトの数ではなく、到達可能なオブジェクトの数に比例するようになったことです。