フリースレッド Python はもはや実験ではありません。私のワークロードで解放されたものは次のとおりです

何年もの間、Python スレッドは一度に複数の CPU コアを使用できませんでした。フリー スレッド ビルドでは状況が変わり、これを書いている時点では正式にサポートされています。ここではそれについて簡単に紹介し、なぜそれが大きな問題になるのかを説明します。

そもそも、フリースレッド Python とは何でしょうか?

GIL は現在オプションですが、トレードオフがあります

Python は初期の頃から、GIL として知られるグローバル インタプリタ ロックを搭載してきました。ロックにより、プロセス内で一度に 1 つのスレッドのみが Python バイトコードを実行できます。これにより、CPython のメモリ管理がシンプルかつ安全に保たれますが、スレッドが CPU に依存する作業をコア間で分散できないことも意味します。実際の並列処理を望む開発者は通常、独自のメモリで個別のプロセスを生成するマルチプロセッシングに到達するか、ロックを解放する C 拡張機能に頼っていました。フリースレッド ビルドでは、制限が完全に削除されます。

PEP 703 で提案され、2024 年 10 月に Python 3.13 の実験として出荷されました。これにより、複数のスレッドが異なるコア上で Python コードを並列実行できます。最初のリリースには実際のコストがかかりました。シングルスレッド コードの実行は著しく遅くなり、一部の内部最適化はまだスレッドセーフではなかったため、オフにする必要がありました。転換点は、ビルドを推進するための基準を設定し、2025 年 6 月に承認された PEP 779 でした。2025 年 10 月にリリースされた Python 3.14 は、それらの基準を満たしました。

ドキュメントでは現在、フリースレッド ビルドがサポートされており、実験的ではなくなっていますが、これはオプションのままであり、デフォルトのインタープリターとは別のものです。コアチームはこれを段階的な計画の第 2 段階として説明しています。後のフェーズでフリー スレッドが唯一のビルドになるかどうかはまだ不明です。

通常の Python コードを高速化する特殊な適応型インタプリタはフリースレッド モードで実行されるようになり、シングルスレッドのペナルティは標準ビルドと比較しておよそ 5 ～ 10% に縮小しました。また、既存のインストールでスイッチを切り替えるのではなく、通常 3.14t というラベルが付けられた個別のビルドをインストールすることによってもオプトインします。 uv などのツールを使用すると、両方のビルドを並べて保存できるため、独自のコードで比較できます。これは同じ言語ですが、その下に異なるランタイムがあります。

実際、それはどのように役に立ちましたか?

マルチプロセッシングのオーバーヘッドのない、実際の並列処理

クレジット: Tony Phillips/How-To Geek

この利点は、複数のスレッドに分割できる CPU バウンドのコードで最も明らかです。ファイルの大規模なバッチの解析と変換、多数のレコードに対するスコアリングや特徴計算の実行、またはワーカー プール内の独立したデータ チャンクの処理を考えてください。標準ビルドでは、ロックによって計算がシリアル化されるため、この作業を実行するスレッド プールはほとんど何も得られません。したがって、チームはマルチプロセッシングに移行しましたが、それによって税金が発生します。すべての引数と結果をピクルしてプロセス間で送信する必要があり、各ワーカーが共有データの独自のコピーを保持するためメモリ使用量が増大し、起動コストが加算されます。

GIL がなくなると、すべてのスレッドがメモリ内の同じオブジェクトを読み取りながら、同じスレッド コードをコア間で拡張できます。これにより、有料のハードウェアを使用するためだけに別のプロセス アーキテクチャが必要なくなるため、シリアル化の手順が削除され、プログラムがよりシンプルになります。利益は、作業がどの程度うまく分割されるかによって決まります。ネットワーク呼び出しまたはディスクの待機にほとんどの時間を費やすジョブは、スレッドに関しては既に問題ありませんでした。これは、ロックが I/O 中に解放されるため、ほとんど変化が見られないためです。

大量の計算と共有状態の大量のロックが混在するジョブは、どのビルドで実行しても拡張性が低下する可能性があります。最良の結果は、独立した部分に分割され、ほとんどの時間を Python コードまたはフリー スレッドと連携するライブラリに費やすワークロードから得られます。それを知る唯一の正直な方法は、測定することです。実稼働環境で実行するマシン上で、両方のビルドで同じスレッド ベンチマークを複数のスレッド数で実行します。シングルスレッドの比較では標準ビルドがわずかに有利になることが予想され、マルチスレッドの比較では切り替えの価値があるかどうかが判断されると予想されます。

誇大宣伝する価値はあるでしょうか？

有望で使えるが、まだデフォルトではない

記事を締めくくるときにいつも言っているのですが、それは状況次第です。ビルドはサポートされていますが、オプトインのままであり、コストはゼロではありません。シングルスレッド コードの実行速度は依然として数パーセント遅いため、計算にスレッドをまったく使用しないアプリケーションは何も得られず、少しだけ損をします。 3.14 の実験的な JIT コンパイラもフリースレッド ビルドではまだ利用できませんが、その強化を期待している場合はこれが重要です。

ここでのより大きな障害は生態系です。 C 拡張機能を含むパッケージには、フリー スレッド インタプリタ用に構築されたホイールが必要ですが、コアの科学Python ライブラリ以外の範囲は依然として不均一であるため、サポートされていない依存関係が 1 つあると採用が妨げられる可能性があります。 2026 年 10 月にリリースされた Python 3.15 は、PEP 803 でこの問題の一部に対処し、abi3t タグが付けられたフリースレッド ビルド用の安定した ABI を追加します。これにより、拡張機能の作成者はフリースレッドのリリース間で動作する 1 つのホイールを公開できるようになりますが、ビルド ツールはまだそれに追いついていません。

独自のコードには、より静かなリスクもあります。 GIL は多くの競合状態を誤って隠しており、GIL を削除すると、決して真にスレッドセーフではなかったコードのバグが露呈する可能性があります。結果を信頼する前に、共有状態を確認し、必要に応じてロックを追加し、負荷をかけた状態でテストしてください。それでも方向性は明確です。主要なライブラリはフリースレッド ビルドを出荷しており、コア チームはこの作業を副次的な実験ではなく長期的な取り組みとして扱っています。ワークロードが CPU 依存で、並列化可能で、互換性のあるパッケージに基づいて構築されている場合は、今すぐ試してください。それ以外の場合は、常に監視し、リリースごとに再テストしてください。

テストする価値はありますが、まだデフォルトではありません

フリースレッド Python は単なる好奇心からサポートされるオプションに移行しました。これにより、CPU 負荷の高い並列作業が得られ、他の部分では多少のコストがかかります。依存関係を確認し、独自のコードのベンチマークを行い、数値が正当化される場合にはそれを採用します。