【ITニュース解説】Python 3.14's concurrent.interpreters module turns a 3.6-second GIL bottleneck into 0.9 seconds

Pythonは多くの開発者に利用される強力な言語だが、これまで並列処理においては「Global Interpreter Lock（GIL）」という仕組みが長年の課題だった。GILはPythonインタープリタが一度に1つのスレッドしかPythonのコードを実行できないようにする制限であり、特にCPUの計算能力を最大限に使うような処理（CPUバウンドな処理）では、複数のスレッドを使っても速度が向上しにくいという問題があった。真の並列処理を実現するには、これまでmultiprocessingモジュールでプロセス単位の並列化を行うか、Python以外の言語で書かれたC拡張を利用するなどの方法が一般的だった。

しかし、Python 3.14で標準ライブラリに新たに登場したconcurrent.interpretersモジュールが、このGILの制約を根本的に覆す。このモジュールは「サブインタープリタ」と呼ばれる機能を利用し、各サブインタープリタが独自のGILを持つことで、CPU集中型のPythonコードでも複数のCPUコアを効率的に使えるようにする。サブインタープリタ自体はPythonの内部で以前から存在していたが、PEP 734という改善提案により、通常のPythonコードから簡単に利用可能になった点が重要である。

実際の検証では、このサブインタープリタの性能が劇的であることが示された。例えば、CPU集中型の作業（40万までの素数を数える処理）を4つの単位に分割し、それぞれを並列実行した場合、従来のGILの制約を受けるOSスレッドを使った方法では、完了までに約3.6秒かかった。これは、単一スレッドで1単位の作業を行うのに約0.8秒かかることを考えると、GILによるオーバーヘッドが大きく、期待通りの並列化ができていないことを示す。一方で、Python 3.14の新しいサブインタープリタを4つ使って同じ4単位の作業を実行すると、驚くべきことに約0.9秒で完了した。これは単一スレッドで1単位の作業を行う時間とほとんど変わらず、追加の3単位の作業が実質的に無料で実行できたことを意味する。この性能は、既存のmultiprocessingモジュールを使ったプロセスによる並列処理（約0.95秒〜1.3秒）と同等であり、サブインタープリタが真の並列実行を可能にすることを明確に示した。

ただし、サブインタープリタを利用する際にはいくつかの特性を理解する必要がある。まず、1つのInterpreterオブジェクトは同時に1つのスレッドからの呼び出ししか受け付けない。もし複数のスレッドで1つのインタープリタを共有し、その中で同時に複数の処理を実行しようとすると、2つ目の呼び出しはすぐにInterpreterErrorというエラーで拒否されてしまう。これは、1つのインタープリタが「アイドル状態」か「実行中」のどちらかであり、中間状態がないためだ。したがって、N個の処理を同時に実行したい場合は、N個のサブインタープリタをそれぞれ用意する必要がある。

また、サブインタープリタの起動コストについても注意が必要だ。サブインタープリタはOSプロセスよりも「軽い」というイメージがあるかもしれないが、検証では4つのサブインタープリタを生成し初期化するのに、従来のforkベースのプロセスプールよりも約2倍の時間がかかり、Python 3.14で新しくなったforkserverというプロセス起動方法と比較してもわずかに時間がかかっていた。しかし、この起動にかかる時間は数十ミリ秒程度と短く、各サブインタープリタで実行する作業が数ミリ秒を超えるようなものであれば、この起動コストは全体の実行時間にほとんど影響を与えない。サブインタープリタの利点は、プロセスのようにメモリ空間を完全にコピーする必要がない点にあり、起動速度の速さにあるわけではないと言える。

さらに、サブインタープリタを終了しても、使用されたメモリがすぐにOSに返却されないという点も考慮すべきだ。close()メソッドでインタープリタを破棄しても、Pythonプロセス全体のメモリ使用量は初期値には戻らず、各サブインタープリタが使用したメモリはプロセス内に保持される傾向がある。これはメモリリークとは異なるが、長期間稼働するプロセス内で多数のサブインタープリタを生成・破棄するようなアプリケーションでは、メモリ消費量の設計に注意が必要となる。

サブインタープリタ間でデータをやり取りする際には、共有可能なオブジェクトの種類に制約がある。整数、文字列、バイト列、None、真偽値、フロート、整数のタプルといった基本的なデータ型は直接共有可能だ。しかし、リスト、辞書、カスタムクラスのインスタンス、threading.Lockなどの複雑なオブジェクトは、デフォルトでは直接共有できない。もしInterpreter.call()メソッドの引数として共有不可能なオブジェクトを渡そうとすると、NotShareableErrorというエラーが発生し、処理が拒否される。この制約を回避するためには、concurrent.interpretersモジュールが提供する「クロスインタープリタQueue」を利用できる。このキューに共有不可能なオブジェクトを投入すると、キューは自動的にそのオブジェクトをpickle（データをバイト列に変換するプロセス）で直列化し、別のインタープリタで受け取る際にunpickle（バイト列から元のデータに復元するプロセス）を行う。この方法では、元のオブジェクトとは異なる新しいオブジェクトが作成されるため、オブジェクトの同一性は失われるが、値は維持される。変更可能なオブジェクトの場合、元のオブジェクトと復元されたオブジェクトの間で状態は同期されない点に留意する必要がある。

なお、Python 3.14では、Linux環境におけるmultiprocessingモジュールのデフォルトのプロセス開始方法がforkからforkserverに変更された。この変更は、if __name__ == "__main__":という慣例的なガード句なしでmultiprocessing.Process().start()を直接呼び出しているような既存のコードに対して、RuntimeErrorを引き起こす可能性があるため、3.14への移行時に注意が必要な変更点である。

この新しいサブインタープリタは、特にこれまでthreadingを使っていたものの、GILの制約で並列処理の恩恵を受けられなかったCPU集中型のワークロードに大きなメリットをもたらす。このようなケースでは、threading.ThreadをInterpreter.call_in_threadに置き換え、データ共有には共有可能タイプを使うか、クロスインタープリタQueueを介してpickle/unpickleを行うことで、真の並列処理を実現できるだろう。既存のmultiprocessingが既にうまく機能している場合は、現時点での明確な移行メリットは少ないかもしれないが、Pythonでより高性能なアプリケーションを開発する上での新たな選択肢として、サブインタープリタの活用は非常に有望である。