Python 3.14のJITコンパイラとは？有効化の手順と3.15.0までの実測、フリースレッド版と新機能

Python 3.14のJITコンパイラは実験的な機能で、python.orgが配布するWindows版・macOS版のバイナリに組み込まれています。既定では無効で、環境変数 PYTHON_JIT=1 を付けて起動したときだけ動きます。公式の見込みは作業内容によって「10%遅くなる〜20%速くなる」です。2026年10月9日に公開された3.15.0ではJITの中身が大きく作り直されましたが、位置づけは実験的なまま、既定も無効のままです。

この記事では、JITが使えるPythonの見分け方と有効化の手順、3.15での変更点、3.14.8と3.15.0での実測を先に説明します。後半ではGILを外したフリースレッド版の並列性能、t-stringなど3.14のそのほかの新機能、3.14.8の修正内容と3.12・3.13からの移行判断を扱います。3.15全体の新機能はPython 3.15の新機能と3.14から上げる手順にまとめています。

まとめ：Python 3.14・3.15のJITと新機能の要点

• JITはpython.orgのmacOS版・Windows版に同梱され、PYTHON_JIT=1 で有効になります。uv（python-build-standalone 20261013）の3.14.8・3.15.0と、Homebrewの3.14.7・3.15.0には入っていませんでした（Intel Macで確認）。
• JITの有無は sys._jit.is_available()、有効かどうかは sys._jit.is_enabled() で確認します。
• 3.15のJITは実行経路を記録するトレース方式に作り直され、公式のpyperformance平均でx86-64 Linuxが7〜8%、AArch64のmacOSが11〜12%速くなりました。位置づけは実験的（experimental）のままで、既定も無効です。
• Intel Macで3.14.8と3.15.0を測ったところ、JITを有効にして一貫して速くなった処理はありませんでした。3.14.8では浮動小数のループが中央値で約4割遅くなり、3.15.0では同じループが約7%速く、fib(30)は約2割遅くなりました。
• Pythonで書いた数値ループを何倍も速くしたいなら、CPythonのJITではなくNumbaやCythonが候補です。
• フリースレッド版（GILなし）は3.14で正式サポートになりました。GILは廃止されておらず、通常版は今もGILありです。3.15.0のmacOSインストーラでは、フリースレッド版が既定で選ばれるようになりました。
• 3.14系の最新は3.14.8（2026年9月30日）で、CVE 6件を直した前倒しのセキュリティリリースです。3.14.4以前を使っているなら、GCの差し戻しも含めて3.14.8へ上げてください。

CPythonのJITコンパイラの仕組みと3.14・3.15での位置づけ

CPython（python.orgが配布する標準のPython）は、ソースコードをバイトコードに変換してインタプリタで1命令ずつ実行します。3.11で入った特化型適応インタプリタ（PEP 659）は、実行中に型を観察してバイトコードを型専用の命令に書き換えます。3.13で入ったJITはこの仕組みの上に乗っていて、何度も実行される区間を「トレース」として切り出し、機械語に変換します。

変換にはcopy-and-patchという方式（PEP 744）を使います。命令ごとの機械語の部品（ステンシル）をCPythonのビルド時にLLVMで生成しておき、実行時はそれを複製して定数やジャンプ先を書き込むだけです。そのため、JITを使う側はLLVMを入れる必要がありません。LLVMが必要なのは、JITを有効にしてCPythonをビルドするときだけです。

3.13ではソースから自分でビルドしなければJITを試せませんでした。3.14からはpython.orgのWindows版とmacOS版のバイナリにJITが入り、既定では無効の状態で配られています。What’s New in Python 3.14は、この状態を「本番環境での使用は推奨しない」と明記しています。3.15.0でも、python.orgのmacOS版のビルド設定は3.14と同じ --enable-experimental-jit=yes-off（組み込み済み・既定は無効）でした。JITという仕組みそのものの一般論は、JITコンパイラの仕組みとAOT・インタプリタとの違いで扱っています。

Python 3.14でJITを有効にする手順と確認方法

JITが入っている配布物の見分け方

同じ版でも、入手元によってJITの有無が違います。2026年10月20日に、手元で入手できた配布物を sys._jit.is_available() と sysconfig.get_config_var("CONFIG_ARGS") で調べた結果です。

ビルド設定の列は、CONFIG_ARGSからJITとtail call interpreterに関係する設定だけを抜き出したものです。フリースレッド版でJITが使えないのは仕様で、3.14のWhat’s Newにも「Free-threaded builds do not support JIT compilation」とあります。3.15.0tのビルド設定も --enable-experimental-jit=no のままでした。uvで入れたPythonにJITが無いのは、3.15.0になっても変わっていません。まず次の1行で確かめてください。

$ python3.14 -c "import sys; print(sys._jit.is_available(), sys._jit.is_enabled())"
True False

1つ目が False なら、そのPythonには環境変数を設定してもJITは入りません。JITを試すならpython.orgのインストーラで入れた版を使います。

PYTHON_JIT=1によるJITの有効化

JITが入っているPythonでは、起動時に環境変数 PYTHON_JIT を 1 にすると有効、0 にすると無効になります。起動後に切り替える関数はありません。スクリプトの中で os.environ["PYTHON_JIT"] = "1" と書いても、3.15.0で sys._jit.is_enabled() は False のままでした。-X jit を付けても有効にはなりません。

# macOS / Linux
$ PYTHON_JIT=1 python3.14 -c "import sys; print(sys._jit.is_enabled())"
True

# Windows（PowerShell）
PS> $env:PYTHON_JIT = "1"
PS> py -3.14 -c "import sys; print(sys._jit.is_enabled())"
True

-E や -I を付けて起動すると PYTHON_ で始まる環境変数がすべて無視され、PYTHON_JIT=1 も効きません。ベンチマークのスクリプトを分離モードで動かすときは、sys._jit.is_enabled() の値もあわせて記録してください。

3.14では、JITで動いている区間をgdbやperfなどのネイティブのデバッガ・プロファイラからたどれません。pdbやprofileなどPython側のツールはそのまま使えます。3.15ではLinuxのgdbとGNUの backtrace() がJITの区間をたどれるようになりました（次章）。

JIT付きCPythonのソースビルド

Linuxなどで自分でビルドする場合は、CPythonのソースを展開したディレクトリでconfigureに --enable-experimental-jit を付けます。3.14のビルドにはLLVM 19の clang と llvm-readobj が必要です（3.14のTools/jit/README.md）。3.15ではLLVM 21が公式のサポート版になり、llvm-objdump と llvm-dwarfdump も要ります（3.15のREADME）。

$ brew install llvm@19          # 3.14 の場合。3.15 は llvm@21
$ ./configure --enable-experimental-jit=yes-off --enable-optimizations --with-lto
$ make -j8

yes-off はJITを組み込んだうえで既定を無効にする指定で、python.orgのバイナリと同じ状態になります。yes なら既定で有効、interpreter を指定すると機械語を生成せずに中間表現を解釈する、デバッグ用のモードになります。

Python 3.15.0でのJITの変更点

3.15.0のJITは、3.14と比べて中身がほぼ別物です。What’s New in Python 3.15が挙げる変更は次のとおりです。

• トレースの取り方：実行経路を推定する方式から、実際に通った経路を記録する方式に作り直されました。単純なオブジェクトの生成や、演算子のオーバーロード・ジェネレータの一部もJITの対象になります。
• レジスタ割り当て：簡単なレジスタ割り当てが入り、スタックへの読み書きを省けるようになりました。
• 最適化の追加：定数伝播が増え、安全な場面では参照カウントの更新を省きます。参照が1つしかないintやfloatは、その場で書き換えます。
• デバッガ対応：Linux（ELF）では、生成した機械語の巻き戻し情報をGDBに登録します。3.14の「gdbやperfからたどれない」という制約が、Linuxのgdbと backtrace() については解消されました。
• 機械語の生成：x86-64とAArch64（macOS・Linux）で、生成する機械語の効率が上がり、そのためのメモリ使用量も減りました。
• ビルド：ステンシルの生成に使うLLVMが19から21に上がりました。

効果について、What’s Newはpyperformanceの幾何平均で「x86-64 Linuxで7〜8%、AArch64のmacOSではtail callインタプリタに対して11〜12%速い」としています。一方で、ベンチマークごとの差は「およそ15%遅いものから2倍以上速いものまで」と幅があります。3.14の「10%遅い〜20%速い」より上振れしていますが、遅くなる処理が残っている点は変わりません。

JIT以外では、3.15から公式のWindows 64bit版がtail callインタプリタでビルドされるようになり、What’s NewはWindows x86-64のpyperformanceで15〜20%速いとしています。3.15で「速くなった」と感じる場合、JITを有効にしていなければ、この変更や通常のインタプリタの改善によるものです。

Intel MacでのJIT実測：3.14.8と3.15.0の処理時間

python.orgの3.14.8と3.15.0のmacOS版を使い、JITを無効・有効にして3種類の処理を計りました。計測機はIntel Core i9-9880H（8コア）・macOS 26.6.2、計測日は2026年10月20日です。1プロセスごとにウォームアップを1回実行したあと7回計って最小値を取り、これを設定を入れ替えながら5プロセス繰り返しました。表は5プロセスの中央値で、括弧内は5プロセスの最小〜最大です。

浮動小数のループはN体計算を簡略にした5要素の二重ループを5万ステップ、文字列と辞書の操作は200万回の文字列連結と dict.get です。JIT無効を基準にした有効時の処理時間（中央値）は、3.14.8でfib(30)が約6%増、浮動小数のループが約41%増、文字列と辞書が横ばいでした。3.15.0では浮動小数のループが約7%減った一方、fib(30)は約20%増、文字列と辞書は約5%増でした。

計測中は同じMacで別の処理も動いており、同じ設定でも5プロセスの値が最大4割ほどばらつきました。範囲が重なる組み合わせも多く、小さな差は誤差の範囲です。それでも、3.14.8の浮動小数のループはJIT有効のほうが遅く、3.15.0では同じループが速くなるという向きは、同じ日に別のスクリプトで3回測ったときも同じでした。この環境では、JITを有効にして一貫して速くなった処理は無かった、というのが結論です。

公式の数字がこれより良好なのは、計測の対象と環境が違うためです。3.15の公式値はx86-64 LinuxとApple Silicon（AArch64）のmacOSでの計測で、今回のx86-64 macOSはどちらにも当たりません。数十行のベンチマークと、実アプリに近い処理を集めたpyperformanceの差も大きいので、自分のコードで計ってから判断してください。

今の段階でJITを本番に入れる理由はありません。3.15でも実験的な機能のままで（本番での使用を推奨しないと明記しているのは3.14のWhat’s Newです）、速くなるかどうかも処理と環境で変わります。CI（継続的インテグレーション）で PYTHON_JIT=1 の列を1本足し、手元の処理が遅くならないかを見ておく使い方が現実的です。

CPythonのJITとNumba・PyPy・Cythonの使い分け

「python jit」で検索すると、上位にはNumbaの記事が並びます。CPythonのJITとは別の仕組みで、効く範囲も導入の手間も違います。

Numbaは関数単位でLLVMを使って機械語に変換し、NumPyの配列を扱うループで数十倍の差が出ることがあります。使い方はNumbaの使い方とインストールにまとめています。PyPyは処理系ごと入れ替える方式で、C拡張を多く使うライブラリとの相性に注意が要ります。同じコードで速度を比べたCython・Codon・Mojoの実測比較も判断材料になります。

CPythonのJITの長所は、コードに手を入れずに全体が少し速くなる可能性がある点です。公式の平均値でも1割前後なので、数値計算を何倍も速くする用途には向きません。数値ループがボトルネックなら、NumbaやCythonを候補にし、対応する型・演算と実際の処理時間を比べてください。純PythonのCPU負荷が高い処理を複数スレッドで並列化できるなら、次章のフリースレッド版も候補になります。業務システムでどの処理系・高速化手段を採るかを含めて相談したい場合は、フルスクラッチ開発の支援も行っています。

フリースレッド版Python（GILなし）の正式サポート

PEP 779によるフリースレッド版の正式サポート化

GIL（グローバルインタプリタロック）は、1つのプロセスの中で同時にPythonのバイトコードを実行できるスレッドを1本に制限する仕組みです。3.13でGILを外したビルドが実験的に入り、3.14ではPEP 779の採択により「正式にサポートされるが選択制」の段階（phase II）になりました。GILが廃止されたわけではなく、通常のPythonは3.15でもGILありで配られています。

3.14では、3.13のフリースレッド版で無効だった特化型適応インタプリタが有効になりました。What’s Newは単一スレッドの性能低下を「プラットフォームとCコンパイラにより約5〜10%」とし、フリースレッド版の解説ページはpyperformanceの平均でmacOS（AArch64）の約1%からx86-64 Linuxの約8%としています。3.15では、対応APIへの移行と再ビルドによって利用できる、フリースレッド版向けのStable ABIである abi3t（PEP 803）が加わりました。

フリースレッド版の入れ方と確認

python.orgのmacOSインストーラでは、「カスタマイズ」の「Free-threaded Python」で入れるかどうかを選びます。インストーラの定義ファイル（Distribution）を見ると、この項目の既定は3.14.8では start_selected="false"（外れている）、3.15.0では start_selected="true"（選ばれている）でした。3.15.0を既定のまま入れると、python3.15t も一緒に入ります。

WindowsではPython install managerの py install 3.14t、uvなら uv python install 3.14t で入ります。macOS・Linuxでは python3.14t で起動します。GILの状態は次のように確かめます。

$ python3.14t -c "import sys; print(sys._is_gil_enabled())"
False

GILなしへの対応を宣言していないC拡張を読み込むと、フリースレッド版でもGILが自動で有効に戻り、警告が1行出るだけで処理は続きます。この挙動を再現した手順はPython 3.13の新機能と3.12との違いで紹介しています。

フリースレッド版の実測：8スレッドの高速化と単一スレッドの処理時間

fib(27)を8回計算する処理を ThreadPoolExecutor に渡し、スレッド数を変えて計りました（3回のうち最速値）。python.orgのインストーラに含まれる通常版とフリースレッド版を使っています。

from concurrent.futures import ThreadPoolExecutor

def fib(n):
    return n if n < 2 else fib(n - 1) + fib(n - 2)

with ThreadPoolExecutor(max_workers=8) as ex:
    list(ex.map(fib, [27] * 8))

GILなしの版は、1スレッドと比べて8スレッドで3.14.8tが約5.1倍、3.15.0tが約5.8倍速くなりました。GILありの版は、スレッドを増やしても349〜591msの範囲で上下するだけで、スレッド数に応じた短縮はありませんでした。JITの実測と同じく計測中は別の処理も動いていたため、倍率は目安です。

単一スレッドでは、JITの実測と同じ3種類の処理（5プロセスの中央値）で、フリースレッド版は通常版（JIT無効）よりfib(30)が約19%、文字列と辞書の操作が10〜22%、浮動小数のループが約41〜42%遅くなりました。浮動小数のループは公式の「5〜10%」より大きく遅れています。処理内容・CPU・ビルド条件が異なるため、この計測だけでは差の原因を特定できません。

CPUを使う処理をスレッドで並列化していて、利用しているC拡張がフリースレッド版に対応しているなら移る価値があります。単一スレッドで動かすWebアプリやスクリプト、浮動小数の計算が中心の処理では、通常版を第一候補にしてください。

Python 3.14のそのほかの新機能

t-string（PEP 750）のTemplate生成とHTMLエスケープ

t を前に付けた文字列リテラルは、f-stringと違って文字列を返さず、string.templatelib.Template を返します。固定部分と差し込み値を分けて受け取れるので、差し込み値だけをエスケープする関数が書けます。

from html import escape
from string.templatelib import Template, Interpolation

def render_html(t: Template) -> str:
    parts = []
    for item in t:
        if isinstance(item, Interpolation):
            parts.append(escape(str(item.value)))
        else:
            parts.append(item)
    return "".join(parts)

name = "<script>alert(1)</script>"
print(render_html(t"<p>{name}さん、ようこそ</p>"))
# <p>&lt;script&gt;alert(1)&lt;/script&gt;さん、ようこそ</p>

t-string自体はエスケープをしません。上の render_html は、HTMLのテキスト部分に値を埋め込むための簡略例です。URL・JavaScript・CSSの文脈には対応していません。SQLにはHTML用のエスケープを流用せず、データベースAPIのパラメータバインドを使います。

アノテーションの遅延評価（PEP 649/749）

型アノテーションは定義時に評価されなくなり、参照されたときに初めて評価されます。クラスの中で自分自身を型に書いても、文字列で囲む必要がなくなりました。

import annotationlib

class Node:
    next: Node | None   # 3.13 では NameError

print(annotationlib.get_annotations(Node, format=annotationlib.Format.STRING))
# {'next': 'Node | None'}

同じクラス定義を3.13.14で実行すると NameError: name 'Node' is not defined. Did you mean: 'None'? で止まります。from __future__ import annotations は引き続き使えます。

標準ライブラリでのZstandard圧縮とサブインタプリタによる並列実行

compression.zstd（PEP 784）でZstandard形式の圧縮と展開が標準ライブラリだけでできるようになり、tarfileやzipfileもZstandardに対応しました。concurrent.interpreters（PEP 734）は、1プロセスの中に独立したインタプリタを複数作る仕組みです。concurrent.futures.InterpreterPoolExecutor を使うと、スレッドプールと同じ書き方で使えます。

from concurrent.futures import InterpreterPoolExecutor

def square(n):
    return n * n

if __name__ == "__main__":
    with InterpreterPoolExecutor(max_workers=4) as ex:
        print(list(ex.map(square, range(8))))
# [0, 1, 4, 9, 16, 25, 36, 49]

エラーメッセージの改善

python.orgの3.14.8で実行して確かめたメッセージです。綴りの誤り・else後のelif・文字列接頭辞の組み合わせ・ハッシュできない要素の4種で、直す箇所が文中に示されます。

構文の変更：finally内のreturnとexceptの括弧

finally ブロックの中で return・break・continue によってそのfinallyブロックの外へ制御を移すと、例外を握りつぶす可能性があるため、コンパイル時に SyntaxWarning が出るようになりました（PEP 765）。挙動の違いはPython continueの使い方とbreakとの違いで扱っています。また、複数の例外を捕まえるときに except ValueError, TypeError: と括弧を省けるようになりました（PEP 758、as を付けない場合のみ）。

Python 3.14.5での世代別ガベージコレクタへの復帰

3.14.0〜3.14.4には最大停止時間を短くするインクリメンタルGCが入っていましたが、本番環境でメモリの使用量が大きく増えたという報告が相次ぎ、3.14.5で3.13と同じ世代別GCに戻されました（What’s Newの3.14.5の項）。3.14.4以前でメモリ使用量が増えていたなら、3.14.5以降に上げれば解消する可能性があります。3.14の新機能としてインクリメンタルGCを紹介している資料は、3.14.4以前の情報です。

Python 3.10〜3.15の速度比較

配布元をuvが使うpython-build-standaloneにそろえ、JIT実測と同じ3種類の処理を各版で計りました（1プロセス7回の最小値を4プロセス分取り、その中央値）。3.14.8と3.15.0は2026年10月13日付けのビルド、3.10〜3.13はuvで入れたものです。いずれもJITは入っていません。

3種類とも大きく速くなったのは3.10から3.11への移行で、15〜44%短くなりました。関数呼び出しの多いfib(30)は、3.14.8と3.15.0がどちらも3.13より約17%短くなりました（3.13.14は4プロセスで260〜369msとばらつきが大きく、範囲は一部重なります）。3.14以降のこのビルドは、命令ごとの小さなC関数を末尾呼び出しでつなぐtail call interpreterを使っていますが、版の違いも含むため、短縮のどこまでがこの方式の効果かは特定できません。What’s Newはこの方式の効果をpyperformanceで3〜5%としています。

浮動小数のループは3.13.14が最も短く、3.14.8は約32%、3.15.0は約22%長くなりました。python.org版の3.14.8では同じ処理の中央値が824msで、同じ版でもビルドによって差が出ます。文字列と辞書は3.11以降1,120〜1,353msの範囲で、はっきりした差はありません。「新しい版ほど全部速い」とは言えないので、上げる前に自分の処理で比べてください。

Python 3.14.8の修正内容とサポート期限

3.14.8で直ったセキュリティの問題

3.14.8は2026年9月30日に出た8回目のメンテナンスリリースで、予定を前倒しした「expedited security release」です。リリースページによると、3.14.7からの修正は約354件で、そのうちCVE番号の付いた問題が6件あります。

• ssl：sni_callback でコンテキストを切り替えたときのuse-after-free（CVE-2026-19445）と、SSLContext.wrap_bio() の server_hostname 検証漏れ（CVE-2026-19553）
• zipfile：bzip2・LZMA・Zstandardの展開でメモリを使い尽くす問題（CVE-2026-15310）
• tarfile：展開フィルタをすり抜けて展開先の外にディレクトリを作れる問題（CVE-2026-19672）
• urllib.request：HTTPPasswordMgr の認証情報が別のスキームに送られる問題（CVE-2026-15806）
• stringprep：Unicode 3.2.0以外の文字属性を参照していた問題（CVE-2026-17084）

Windows・macOS版に同梱のOpenSSLは3.5.9に、Expatは2.8.5に更新されています。利用者がアップロードしたzipやtarを展開する処理、TLSのサーバーを動かしている処理があるなら、3.14.7以前から早めに上げてください。なお、macOS 27.0ではIDLEなどtkinterを使うアプリがダイアログを開くと固まる問題があり、リリースページはTkに依存するならmacOS 27.0への更新を待つことも勧めています。

3.12・3.13・3.14・3.15のサポート期限

日付はpeps.python.orgが公開しているリリース情報（python-releases.json）によります。3.13も2026年10月でバグ修正が終わり、バイナリのインストーラが出ない段階に入りました。

3.12・3.13からの移行先選定：3.14と3.15の比較

3.12との主な違いは、フリースレッド版の正式サポートとJITの配布、t-string、アノテーションの遅延評価、エラーメッセージの改善です。3.13でcgiやtelnetlibなど19の標準モジュールが削除されているので、3.12から上げる場合はその影響も確かめます。

業務のコードを今上げるなら、移行先は3.14が妥当です。3.15.0は公開から日が浅い最初の正式版です。NumPyは2.5.4（2026年10月10日公開）で3.15向けのwheelを出していますが、移行前には利用する各ライブラリについて、必要なバージョン・OS・CPU向けのwheelがあるかを確認してください。加えて3.15はUTF-8が既定の文字コードになり（PEP 686）、Windowsでencodingを省略した読み書きの結果が変わります。3.15はCIで動作確認を始め、依存ライブラリの対応を見てから切り替えてください。3.14で作った仮想環境の bin には、数学用イタリック体のπ（U+1D70B）に続けて thon と書く 𝜋thon というコマンドも作られます。版番号が円周率と同じ3.14であることにちなんだ遊びで、中身は通常の python と同じです。複数の版を切り替えて使うなら、pyenvでPythonのバージョンを切り替える手順も参考になります。

よくある質問

Python 3.14のJITコンパイラはどうやって有効化しますか？

python.orgのWindows版・macOS版の3.14を入れ、環境変数 PYTHON_JIT=1 を付けて起動します。sys._jit.is_available() が False を返すPythonではJITは使えません。今回調べた範囲では、uvとHomebrewで入れた3.14・3.15と、フリースレッド版が該当します。

JITを有効にすると必ず速くなりますか？

なりません。公式の見込みは3.14で10%遅い〜20%速い、3.15でもベンチマークによって15%遅いものから2倍以上速いものまで幅があります。Intel Macでの3.14.8・3.15.0の実測では、処理によって速くも遅くもなりました（浮動小数のループは3.14.8で約4割遅く、3.15.0で約7%速い）。自分の処理で計ってから判断してください。

Python 3.14でGILは廃止されましたか？

廃止されていません。GILを外したフリースレッド版（python3.14t）が正式サポートになりましたが選択制で、通常のPythonは3.15でもGILありのままです。

Python 3.12と3.14の違いは何ですか？

3.14にはフリースレッド版の正式サポート、公式バイナリへのJIT同梱、t-string、アノテーションの遅延評価、compression.zstd が加わっています。途中の3.13でcgiやtelnetlibなど19の標準モジュールが削除されたため、3.12からの移行ではその影響も確認が必要です。

Python 3.15でJITは既定で有効になりましたか？

なっていません。3.15.0（2026年10月9日公開）でもJITは実験的な機能で、python.orgのmacOS版は3.14と同じく組み込み済み・既定は無効の設定でした。トレース方式の作り直しやレジスタ割り当てで中身は大きく変わっています。

関連記事

• JITコンパイラとは？仕組み・AOTとインタプリタとの違いと主要言語の実装
• Python 3.15の新機能｜遅延インポートとUTF-8既定化、3.14から上げる手順
• Numbaとは？Pythonを高速化するJITコンパイラの使い方とインストール
• Python 3.13の新機能と3.12との違い｜GIL無効化の実測・削除モジュール・サポート期限
• Cython・Codon・Mojo実測比較｜Pythonコードは何倍速くなるか