Python 3.13 の使い方が間違っています

Python 3.13 では、画期的な変化が約束されていました。開発者たちは、PEP 703 とその Global Interpreter Lock (GIL) を排除する可能性を巡る大規模な誇大宣伝に後押しされ、真に並列な Python の登場を熱望していました。この実験的な機能は、マルチスレッドのCPUバウンドなワークロードにおけるPythonの長年の制限に終止符を打ち、大幅なパフォーマンス向上を告げるものでした。

決定的に、広範な誤解が根付いています。Default Python 3.13 のインストールでは GIL は削除されません。最新バージョンにアップデートする多くの開発者は、重要な違いを見落とし、知らず知らずのうちに「間違ったPython」をインストールしていました。標準ビルドは GIL を維持しており、彼らが求めていたパフォーマンス向上を無効にしています。

その結果、アプリケーションを Python 3.13 に移行するチームは、マルチスレッドコードでパフォーマンスの改善が見られないことがよくあります。彼らのCPUバウンドなタスクは、Python 3.12 と同様に Global Interpreter Lock によって制限され、引き続き順次実行されます。これは、約束された4倍の高速化が全く手の届かないままであるため、広範な混乱と不満につながっています。

この不可解な停滞は、真の並列処理のために設計された特殊なバージョンではなく、従来の Python リリースをインストールしていることに起因します。広く宣伝されている GIL フリーの機能は、特定のビルドの背後に隠されており、ほとんどの人が見落としているニュアンスです。ほとんどの開発者は「間違ったPython」をインストールし、意図せず並行操作のためにシングルコア実行を継続する道を選んでいました。

Python 3.13 の真の可能性を解き放つには、全く異なるアプローチが必要です。開発者は、単純なバージョンアップグレードが GIL フリーをもたらすという仮定を捨てなければなりません。ほとんどの開発者が見落としている真の解決策は、Python 3.13 の明確な free-threaded build にあり、マルチコア処理と約束されたパフォーマンス革命への真の道筋を提供します。

Python 3.13 は、真のマルチコア並列処理のために作られた全く別のインタープリタである公式の free-threaded build を導入しています。`python3.13t` のように '-t' サフィックスで識別されることが多いこの特殊なバージョンは、CPython の並行性を長らく制限してきた Global Interpreter Lock (GIL) の制約を明示的にターゲットにしています。自動的な GIL 削除を期待していた場合、ほとんどの開発者は「間違ったPython」をインストールしていました。

これはデフォルト設定ではありません。オプトイン体験です。開発者は、重要な --disable-gil フラグを使用してインタープリタをコンパイルするこのビルドを意図的に選択する必要があります。このフラグは CPython の内部アーキテクチャを根本的に変更し、GIL の粗粒度ロックメカニズムを、より粒度の細かいメモリ管理のための atomic reference counting システムに置き換えます。この変更により、インタープリタは複数の Python スレッドを異なる CPU コアで同時に実行できるようになり、以前のバージョンからの大きな進歩となります。

CPUバウンドなワークロードにとって、パフォーマンスへの影響は甚大です。GIL が有効なままの Default Python 3.13 が複数のコアを利用するのに苦労する一方で、`python3.13t` は劇的な高速化を達成できます。ベンチマークでは、CPU負荷の高いタスクが最大4倍速く実行され、利用可能なプロセッサ全体で真の並列処理を示しています。例えば、同じマシン上の同じCPUバウンドコードで、Default Python 3.13 はCPUコアをほとんど使用せずに約2.5秒で完了しますが、Python 3.13t は真の並列処理により0.5秒未満で完了します。

開発者は標準のPython 3.13とそのフリースレッド版を同時にインストールできます。WindowsまたはmacOSでは、公式インストーラーに「free-threaded」チェックボックスがあり、個別の実行ファイルが作成されます。Linuxユーザーや`pyenv`で環境を管理しているユーザーは、`pyenv install 3.13t`を具体的に要求できます。GILフリー環境の検証は簡単です。Python 3.13tを開き、`sys.is_gil_enabled()`を実行します。`False`が返されれば、GILの無効化が成功し、実際にGILなしで実行されていることを確認できます。

しかし、この強力な機能にはトレードオフがあります。シングルスレッドのコードは、アトミック参照カウントのオーバーヘッドにより、30〜50%遅くなる可能性があります。さらに、一部のC拡張機能は、GIL無効化環境との互換性を確保するために再構築または更新が必要です。しかし、Python 3.13tは計算負荷の高いサービスに計り知れない可能性を提供します。開発者はすべてを一夜にして移行すべきではありません。代わりに、特定のCPU負荷の高いバックグラウンドワーカー、データ処理、または計算集約型サービスを`python3.13t`の導入対象とし、UVやpyenvのようなツールを使用して実際のワークフローを慎重にテストしてください。

Python 3.13の実験的なGILフリー機能を活用しようと熱望する多くの開発者を待ち受ける重大な誤解があります。それは、標準のアップデートやインストールでfree-threaded buildが提供されると仮定することです。ほとんどの開発者はPython 3.13を誤ってインストールしています。なぜなら、デフォルトで取得する`python3.13`実行ファイルには依然としてGlobal Interpreter Lockが含まれており、マルチスレッドコードがPython 3.12よりも速く実行されないためです。特別な`python3.13t`バージョンが必要です。

WindowsおよびmacOSでは、free-threaded buildの入手は簡単ですが、注意が必要です。公式のPython 3.13インストーラーを実行する際、特定の「free-threaded build」オプションを見つけてチェックするようにしてください。この操作により、標準の`python3.13`と特殊な`python3.13t`の両方の実行ファイルがインストールされます。

Linuxユーザーや`pyenv`のようなツールで複数のPythonバージョンを管理しているユーザーは、よりシンプルなコマンドを利用できます。`pyenv install 3.13t`を実行することで、free-threaded variantを直接インストールできます。このコマンドは、GILなしでPythonをコンパイルするために必要な特定のビルドフラグを処理し、システムに`3.13t`インタープリターを提供します。

上級ユーザーやカスタム環境を構築しているユーザーにとって、ソースからPythonをコンパイルすることは、きめ細かな制御を可能にします。ビルドを構成する際、`./configure`スクリプトに`--disable-gil`オプションを渡してください。この操作により、結果として得られるPythonバイナリがGILなしで実行され、CPUバウンドなタスクに対して真の並列処理のすべての利点を提供します。

検証なしにインストールが成功したと決して仮定しないでください。Python 3.13tを開き、`sys.is_gil_enabled()`を実行します。この関数が`False`を返した場合、free-threadedバージョンが正常に実行されています。実験的なGIL削除の取り組みについてさらに深く掘り下げるには、公式ドキュメントを参照してください: What's New In Python 3.13 — Python 3.14.5rc1 documentation。

覚えておいてください、単純な`pip install --upgrade python`やパッケージマネージャーのアップデートでは、GILフリーのPythonは提供されません。`3.13t` buildを明示的にターゲットにするか、`--disable-gil`でコンパイルする必要があります。この重要なインストール手順を無視すると、マルチスレッドアプリケーションはPython 3.13が克服しようとしているまさにそのロックによって制約されたままになります。

WindowsおよびmacOSでのインストールという迷路を乗り越えた後も、重要なステップが残っています。それは検証です。「うまくいったと仮定するな」がここでのマントラであり、Global Interpreter Lockがまだ有効な状態でコードを実行してしまうことに対する重要な安全策です。Python 3.13のインストーラーの指示に従った後でも、ほとんどの開発者はPythonを誤ってインストールしています。

Python 3.13では、この目的のために新しい専用関数 `sys.is_gil_enabled()` が導入されました。この重要なチェックはPython 3.13以降のバージョンでのみ利用可能で、PythonインタープリターがGILありで動作しているか、なしで動作しているかについて明確な答えを提供します。この特定の関数がなければ、GILのステータスを確認することは著しく複雑になるでしょう。

このチェックを実行するには、ターミナルからPythonを開くだけです。free-threaded buildをインストールしている場合は、`python3.13t` または `py -3.13t` として明示的に呼び出します。その後、`sys` モジュールをインポートして関数を実行します。

```python import sys sys.is_gil_enabled() ```

適切にインストールされたfree-threaded buildを実行すると、出力は `False` になります。これは、インタープリターが実際にGILなしで実行されており、PEP 703によって約束されたマルチスレッドのCPUバウンドタスクの真の並列処理を解放していることを確認します。この `False` は、コードが複数のCPUコアを活用できるようになったことを示します。

逆に、Default Python 3.13環境（ほとんどの開発者がインストールしているPythonのバージョン）で同じコマンドを実行すると、結果は `True` になります。これは、GILがアクティブなままであり、GIL削除に関するすべての宣伝にもかかわらず、マルチスレッドのPythonコードを実質的に単一コアに制限していることを示します。この区別はパフォーマンスにとって不可欠です。

したがって、常にPython環境を確認してください。`True` と `False` の違いは単なるブール値ではありません。それはCPU負荷の高いワークロードで潜在的に2〜4倍高速な実行への入り口ですが、Python 3.13tはこの明示的なチェックを要求します。

free-threaded buildによって劇的なパフォーマンスの違いが現れ、Pythonが現代のハードウェアを活用する方法を根本的に変えます。集中的なCPU-boundタスクの場合、`t-build`は画期的な速度向上をもたらし、Pythonをシングルコアのボトルネックから真のマルチコア利用へと移行させます。これは単なる最適化ではなく、パラダイムシフトです。

ビデオの直接比較を考えてみましょう。同じマシンで実行される同一のCPUバウンドコードです。Global Interpreter Lock (GIL)に依然として束縛されているDefault Python 3.13は、このタスクを約2.5秒で完了します。重要なことに、これはCPUコアをほとんど使用せず、処理能力の大部分をアイドル状態にし、Pythonバイトコードを並行して実行できないままにしています。

しかし、Python 3.13tはこの歴史的な制限を打ち破り、同じワークロードを0.5秒未満で完了します。この特殊なビルドは、利用可能なCPUコアを完全に飽和させることで驚異的な速度を達成し、複数のスレッドがプロセッサ全体で同時に実行される真の並列処理を示します。これは理論的なものではなく、マルチスレッド操作においてCPythonではこれまで達成できなかった具体的なハードウェア利用です。

この顕著な対照は、`t-build`の根本的な設計変更、特にPEP 703の実装に由来します。これにより、PythonスレッドはGILの逐次実行制約から解放され、絶え間ないロックとアンロックなしに、個別のプロセッサコアで真に並行して実行できるようになります。これは、現代のマルチコアCPUに固有の実際のハードウェア並列処理を解放し、Pythonアプリケーションのスケーリング方法を変革します。

多くの計算集約型アプリケーションにとって、これは適切に構造化されたCPUバウンドなワークロードにおいて、直接的に4倍の速度向上につながります。ベンチマークの例では、2.5秒かかっていた処理が0.5秒未満で完了し、この劇的な改善を鮮やかに示しています。利用可能なコア数と特定の計算要件によっては、速度向上が4倍を大幅に超えることも多く、データ処理、科学計算、計算負荷の高いバックグラウンドサービスといった分野におけるPythonのパフォーマンスに対する期待を根本的に変える可能性があります。

Python 3.13tは並列タスクにおいて目覚ましい速度を約束しますが、大きなトレードオフが存在します。Global Interpreter Lock (GIL)を無効にすると、シングルスレッドコードに対して大幅なパフォーマンスペナルティが発生し、従来のGILが有効なビルドと比較して30〜50%遅くなることがよくあります。これは、明示的に並行処理用に設計されていないアプリケーションのどの部分でも、実行速度が著しく低下する可能性があり、慎重に管理しないとシステム全体が遅くなる可能性があることを意味します。

この速度低下は、Pythonの内部アーキテクチャに対する根本的な変更に起因します。フリースレッドビルドは、GILの粗粒度な単一点ミューテックスを、よりきめ細かいロックメカニズムと、すべてのPythonオブジェクトに対するアトミック参照カウントに置き換えます。これらの新しい安全対策は、中央のロックなしで複数のスレッド間でデータ整合性を維持するために不可欠であり、固有のオーバーヘッドを導入します。各オブジェクト操作には追加のチェックと同期コストが発生するようになり、GILが厳密なシーケンシャルアクセスを強制していたときに利用可能だったパフォーマンスショートカットが妨げられます。

実行速度だけでなく、メモリフットプリントにも顕著な影響が見られます。初期報告によると、フリースレッドPythonはGILが有効なバージョンと比較して2〜3倍多くのメモリを消費する可能性があります。この消費量の増加は、スレッドセーフなオブジェクト管理に必要な追加のメタデータとオーバーヘッド、およびより複雑なロック構造に起因します。このようなメモリ要件は、メモリ集約型アプリケーション、大規模データ処理、またはリソースが制約された環境でのデプロイにおいて重要な要素となり、慎重なプロファイリングとリソース計画が必要となります。

その結果、`python3.13t`ビルドはすべてのPythonコードに対する普遍的な解決策ではありません。この特殊なインタープリタは、タスクが真にCPUバウンドであり、真のマルチコア並列処理の恩恵を受けられるシナリオ、例えば重いバックグラウンドワーカー、複雑なデータ処理、計算集約型サービスなどで排他的に輝きます。一般的なスクリプティング、I/Oバウンドなアプリケーション、またはまだ並行処理に最適化されていないコードベースの場合、予測可能なシングルスレッドパフォーマンスを持つDefault Python 3.13が、多くの場合、より優れた安定した選択肢となります。

もう一つの重要な考慮事項はC拡張機能です。既存のほとんどの拡張機能は、GILの存在を前提としてコンパイルされているため、フリースレッドビルドで正しく機能するには再構築または大幅な更新が必要になります。開発者は依存関係が互換性があることを確認する必要があります。GILなしでの実行をサポートする拡張機能は、`Py_mod_gil`スロットを明示的に利用する必要があります。拡張機能の適応に関するさらなる技術的洞察とガイダンスについては、Python support for free threading — Python 3.14.5rc1 documentationの公式ドキュメントを参照してください。互換性を前提とせず、移行前に依存関係スタック全体を厳密にテストすることが不可欠です。

フリースレッドの Python 3.13 は並列性を解き放ちますが、既存のC拡張機能は大きな障害となります。以前のPythonバージョンに対してコンパイルされた多くの人気ライブラリやツールは、スレッドセーフティのために暗黙的にGlobal Interpreter Lockに依存しています。GILがないと、これらの拡張機能は不安定になり、クラッシュしやすくなったり、複数のスレッドが共有リソースを同時に変更しようとする際に、微妙でデバッグが困難な競合状態を引き起こしたりします。

歴史的に、GILは包括的なミューテックスとして機能し、一度に1つのスレッドのみがPythonバイトコードを実行することを保証していました。C拡張機能は、共有データ構造への同時アクセスをGILが管理すると信頼し、明示的なロックメカニズムやクリティカルセクションの保護をしばしば省略していました。この基本的な保護を取り除くことは、これらの拡張機能を深刻な問題に晒し、スレッドモデルとミューテックスやアトミック操作のような明示的な同期プリミティブの完全な再評価を要求します。開発者は、真にスレッドセーフになるために、Cコードの大部分を移植または書き直す必要があります。

Pythonは、この重要な移行のために、モジュール定義構造内に`Py_mod_gil`スロットを提供しています。拡張機能は、このスロットを設定することで、フリースレッドビルドとの互換性を明示的に宣言し、GILの保護なしに並行処理を扱うことを示さなければなりません。この重要なフラグは、拡張機能がGILのない環境で安全に動作できるかどうかをPythonインタープリターに伝えます。この明示的な宣言がない場合、インタープリターはGILへの依存を仮定し、拡張機能のロードを拒否したり、即座に不安定性を引き起こしたりする可能性があります。

重要な注意点があります。一部のサードパーティパッケージは、GILフリー環境を検出し、自身の安定性を保証し予期せぬ障害を防ぐために、内部的にGILを積極的に再有効化する可能性があります。これは即座のクラッシュを防ぎますが、その特定のパッケージとやり取りするコードにとって、フリースレッドのPythonビルドを実行することによるパフォーマンス上の利点を完全に打ち消します。ユーザーは、依存関係ツリーを精査し、すべての重要なC拡張機能がGILレス実行モデルをサポートしていることを確認して、Pythonの並列処理の可能性を真に解き放つ必要があります。これには、慎重なテストと、場合によってはアップストリームライブラリの更新を待つことが必要です。

フリースレッドビルドでPythonの真の可能性を解き放つには、全面的な移行ではなく戦略的な展開が必要です。アプリケーションのボトルネックを特定してください。GILなしの環境は、真の並列処理を要求するCPU負荷の高いシナリオで最も輝きます。これには、大規模なデータセットを処理するバックグラウンドワーカー、集中的な科学計算シミュレーション、および大規模なデータ処理パイプラインが含まれます。計算負荷の高いマイクロサービスも、複数のコアを活用して並行タスクを同時に実行することで、大きな利益を得ます。ここでは、マルチスレッドのCPUバウンドコードを用いたベンチマークで示されたように、4倍の速度向上という可能性が具体的な現実となり、実行時間を変革します。

逆に、多くの一般的なユースケースでは、デフォルトのPython 3.13ビルドが最適な選択肢であり続けます。高トラフィックのウェブサーバーが`asyncio`を活用して並行ネットワーク操作を行うようなI/Oバウンドアプリケーションは、GILの削除から何の利点も得られません。そのパフォーマンスは、CPUバウンドのPython実行ではなく、データベースクエリやAPI呼び出しのような外部要因に依存します。同様に、シングルスレッドスクリプトはフリースレッドビルドでは明らかに遅くなります。GILの内部最適化に代わるアトミック参照カウントのオーバーヘッドが増加するため、30〜50%の大幅なパフォーマンス低下を経験する可能性があります。

したがって、アプリケーション全体を一晩で移行しようとしないでください。そのようなアプローチは、解決する問題よりも多くの問題を引き起こすリスクがあります。よりスマートで実用的な戦略は、外科的な精度を伴います。コードベース内で真にCPUバウンドなコンポーネントのみを特定し、分離します。これらの特定のモジュールまたはサービスを、独立した専用のfree-threaded Python環境で実行します。この戦略は、「C Extension Minefield」からのリスクを軽減し、アプリケーションの他の部分でのパフォーマンス低下を回避し、安定性や全体的な速度を損なうことなく、最も効果的な場所でメリットを最大化します。これは、ターゲットを絞った最適化です。

このターゲットを絞った移行をシームレスに促進するために、堅牢な環境管理ツールを活用してください。`pyenv`や`uv`のようなユーティリティを使用すると、開発者は同じマシン上で異なるPythonビルドを簡単にプロビジョニング、管理、切り替えできます。特定の環境を設定し、例えば`pyenv install 3.13t`を実行して高性能コンポーネント用のfree-threadedビルドを具体的にターゲットにしながら、残りの部分にはdefault Python 3.13を維持することができます。この柔軟性により、適切なPythonを適切なジョブにデプロイし、妥協することなくスタック全体のパフォーマンスを最大化し、異なる構成のテストを簡素化できます。

Python 3.13のfree-threadedビルドは、最終的な目的地ではなく、大胆で実験的な最初の一歩を示しています。この数年間にわたる移行は、並列ビルドを導入し、真に並行なPythonの基礎を築きます。これは、初期のPythonバージョンが主要な最適化の前にコア構文を確立したのと同様に、根本的な変化を表しています。

Python 3.14から始まる将来のPythonイテレーションでは、このアーキテクチャが洗練されます。開発者は、初期のfree-threadedビルドで観察された30-50%のシングルスレッドパフォーマンスオーバーヘッドを軽減するために積極的に取り組んでいます。メモリ管理の大幅な改善と、既存のC拡張機能との互換性の向上が期待され、これはより広範な採用にとって重要です。

長期的なビジョンは明確です。free-threadedビルドはdefault Pythonになることを目指しています。コミュニティの議論では、この重要な変更の潜在的なターゲットとしてPython 3.16または3.17が挙げられており、Python実行の新しい標準を確立します。これには、広範なエコシステムの更新と堅牢な安定性が必要です。

この取り組みは、歴史的なPython 2からPython 3への移行の規模と複雑さに匹敵します。ライブラリとアプリケーションのスムーズな移行を確実にするために、コア開発者とより広範なコミュニティからの協調的な努力が求められます。`sys.is_gil_enabled()`のような初期の機能は、[Add sys._is_gil_enabled() #117514 - python/cpython - GitHub]のような議論で見られるように、開発者がGILステータスを確認するための道を開く重要な追加でした。

繰り返します：「すべてを一晩で移行しないでください。」Python 3.13のfree-threaded buildは革新的ですが、慎重な検討が必要です。これは、すべてのプロジェクトにとって単純なバージョンアップグレードではなく、重要なアーキテクチャの変更を表しています。この移行には戦略的に取り組み、一括置換の考え方を避けてください。

特定のプロジェクトで切り替えを検討していますか？free-threadedビルドにコミットする前に、これらの重要な要素を評価してください。これは普遍的なアップグレードではなく、特定のパフォーマンスボトルネックのための専門ツールです。

開発者は次の点を問いかけるべきです： - あなたのアプリケーションは明らかにCPU-boundであり、真のマルチスレッド用に設計されていますか？潜在的な4倍の速度向上は、真の並列処理があって初めて実現します。 - すべての重要なC extensionsの互換性を確認しましたか？多くの既存ライブラリは、GILなしで正しく機能するために再コンパイルまたは更新が必要です。 - あなたのチームは、実世界のワークロードで厳密なベンチマークを行うことにコミットできますか？オーバーヘッドの増加により、Single-threaded操作では30〜50%の速度低下が発生する可能性があります。 - 必要に応じて、2つの異なるPython環境を管理する準備はできていますか？`python3.13t`実行ファイルは、Default Python 3.13と並行して存在します。

絶え間ない実験の文化を奨励しましょう。管理された環境でfree-threaded buildを展開し、既存のPython 3.12またはDefault Python 3.13セットアップに対してパフォーマンスを綿密にベンチマークしてください。「信頼せよ、しかし確認せよ：あなたのGILは本当に消えたのか？」という原則は依然として最重要です。あなたの特定のユースケースからのデータのみが、真の影響を明らかにします。

結局のところ、free-threaded buildは万能薬ではありませんが、Pythonの矢筒に加わる強力な新しい矢です。CPU-heavy background workers、scientific computing、data processingのような適切なワークロードに慎重に適用された場合、これまで達成できなかった真の並列パフォーマンスの時代を切り開きます。Python 3.13におけるこの実験的な一歩は、言語の未来にとって刺激的な道筋を示しています。

Python GILとは何ですか？

Global Interpreter Lock (GIL)は、単一プロセス内で一度に1つのスレッドのみがPython bytecodeを実行できるようにするmutexであり、マルチコアプロセッサ上でのCPU-bound tasksに対する真の並列処理を制限します。

Python 3.13ではGILはデフォルトで削除されていますか？

いいえ。標準のPython 3.13ビルドでは、GILはまだ有効になっています。GILなしで実行するには、特別な「free-threaded」ビルド（しばしばpython3.13tと呼ばれます）をインストールする必要があります。

私のPython環境でGILが無効になっているかを確認するにはどうすればよいですか？

Python 3.13+インタープリタで、`import sys`を実行し、次に`sys.is_gil_enabled()`を実行します。`False`の戻り値は、そのインタープリタでGILが無効になっていることを確認します。

GILを無効にすると、すべてのPythonコードが速くなりますか？

Not necessarily. It provides significant speedups for multi-threaded, CPU-bound code. However, single-threaded code and some C extensions can actually run slower due to new overhead.