世界を動かす技術を、日本語で。

フリースレッドPythonの初年度

概要

  • CPython 3.14.0b1 のリリースと PyCon 2025 開催が、free-threaded Python実現の重要な節目となることを説明。
  • Quansightチームが free-threadedビルド の実験的利用を現実のワークフローで可能にした経緯を紹介。
  • GIL無効化 によるパッケージの課題やエコシステム全体の現状を整理。
  • 主要パッケージやコアモジュールへの スレッドセーフ化対応 の進捗を列挙。
  • 今後の課題・貢献方法・コミュニティへの参加を呼びかける。

Free-threaded Pythonの1年:Quansightとエコシステム対応の最前線

Free-threaded Pythonの意義と課題

  • CPython 3.14.0b1 リリースと PyCon 2025 開催は、free-threaded Python実現に向けた重要な節目となることを確認。
  • Quansightチームは、 free-threadedビルド を複雑な依存関係を持つ実運用ワークフローで試験的に利用可能にすることに貢献。
  • free-threaded Python により、マルチコアCPUやGPUの計算資源を最大限活用できることを強調。
  • GIL有効時 は並列アルゴリズム活用に制約があり、threadingモジュールの利用は限定的であることを説明。
  • multiprocessing はプロセス生成やデータコピーコストが高く、マルチスレッドプログラムの利点が活かせないことを指摘。
  • ネイティブコードを含むパッケージは、 free-threadedビルド 対応にあたりスレッドセーフ性の監査が必須となることを強調。
  • GIL無効化 はCPythonインタプリタの構造的な大改修を伴い、既存パッケージの構造的な修正も必要となることを説明。
  • C拡張内のグローバル状態利用は、 GIL無効時 にはデータ競合を引き起こす危険があることを確認。
  • threadingモジュール 利用時にも理論上はスレッドセーフ問題が発生しうるが、GILにより多くは表面化しなかったことを補足。
  • free-threadedビルド ではこうした問題の顕在化と修正が急務となることを明示。

主な成果と対応パッケージ

  • QuansightとMeta Pythonランタイムチームは、多数のパッケージ・プロジェクトで free-threaded Python対応 を推進。
    • meson, meson-python, setup-python GitHub Actions, packaging, pip, setuptoolsなどの ビルド・ワークフロー系ツール 対応。
    • Cython, pybind11, f2py, PyO3などの バインディング生成ツール 対応。
    • NumPy, SciPy, PyArrow, Matplotlib, pandas, scikit-learn, scikit-imageなどの PyData基盤パッケージ 対応。
    • Pillow, PyYAML, yarl, multidict, frozenlistなどの PyPI主要依存パッケージ 対応。
  • 現在もCFFI, cryptography, PyNaCl, aiohttp, SQLAlchemy, grpcio, safetensors, tokenizersなど 未対応パッケージ への対応を進行中。
  • QuansightチームのCPythonコア開発者は、以下の 主要改善 に貢献:
    • warningsモジュールの デフォルトスレッドセーフ化 (free-threadedビルド)、GIL有効時もオプションで有効化可能。
    • asyncioの スレッドセーフ問題修正 と、スレッドプールランナー利用時の並列スケーリング性能向上。
    • ctypesモジュールの スレッドセーフ化刷新
    • free-threadedガーベジコレクタの 性能向上
    • deferred reference countingスキームの実装支援。
    • adaptive specializing interpreterの最適化、free-threaded CPython 3.14の シングルスレッド性能向上
    • 多数のバグ修正・スレッドセーフ化改善を実施。
  • free-threaded Python対応ガイド を執筆し、今後のパッケージ対応の参考資料として公開。

エコシステムの現状と進捗

  • 1年前の Python 3.13.0b1 時点では、free-threadedビルドでほぼ全てのパッケージがビルド不可状態だったことを説明。
  • 問題の多くは 根本的な障害 ではなく、デフォルトオプションや軽微な前提の破綻によるものだったことを指摘。
  • パッケージメンテナやコミュニティと連携し、多数の問題を解消し、現状は大幅に改善されたことを報告。
  • Cython 3.1.0 のリリースによる公式free-threaded対応が、ビルド問題の大きな解決策となったことを説明。
  • 依然として 未対応のコンパイル済みコード含有パッケージ への対応を継続中。
  • 進捗は 手動更新のステータステーブル やHugo van Kemenadeの 自動トラッカー で確認可能。

現在の課題と今後の展望

  • free-threaded Pythonビルド は実験利用に十分な状態であり、実際のワークフローでの性能・バグ報告が求められていることを呼びかけ。
  • multiprocessing利用時のコスト削減や 並列性能向上 が期待できる一方、多くのパッケージで スレッドセーフ監査 が必要。
  • 多くのPythonライブラリは ミュータブルなデータ構造 を提供しており、スレッドセーフ・マルチスレッド性能に関するドキュメントが不十分であることを指摘。
  • 大規模なレガシーパッケージでは、対応のためのリソースや知見が不足しているケースが多いことを課題として挙げる。
  • コミュニティ全体で依存ツリーの問題を把握し、 持続可能な保守体制 構築を目指すことの重要性を強調。

貢献方法とコミュニティへの参加

  • free-threadedガイド のコントリビューションガイド参照を推奨。
  • Quansight-Labs GitHub orgの free-threaded-compatibilityリポジトリ でエコシステム全体の課題をトラッキング・ガイド執筆を実施中。
  • コミュニティDiscord も開設し、free-threadedビルド対応の議論・協力を促進。
  • 興味がある場合はぜひ参加・協力することを推奨。
  • PyConでの 発表 も予定しており、YouTube録画が今後の学習資源となることを期待。
  • free-threadedビルド がPython言語の未来であり、今後数年で日常的に使われるパッケージ群の性能向上に寄与することを展望。

Hackerたちの意見

PythonがGILを失う日が来るのがちょっと怖いのは俺だけかな?Pythonの開発者たちは、自分たちが何を求めているのか分かってないと思う。どんな言語でも複雑なマルチスレッドコードはあまり信頼できないし、特にPythonのような動的な言語では一番信頼できないよ。

GILがあるかないかは、マルチコアのワークロードを実行したい人だけの心配事だよ。もしまだコードをスレッドやマルチプロセスで動かすことに時間を使っていないなら、実際にはほとんど変わらない。GILに関係なく考えなきゃいけないレースコンディションの問題は、元々存在してるからね。

君の不安を増やしたくはないけど、LLMはGILが存在する前提で何十年分のPythonコードで訓練されていることも忘れないでね。

より現実的に言うと、ML/AIのシーンで起こったように、知識のある人たちが複雑なライブラリを書いて、それを科学者や経験の少ない、リスクを避けたい開発者たちに渡すことになると思う(それ自体は悪いことじゃない)。Pythonが長年にわたって得たクリティカルマスのおかげで、GILは場合によってはかなり厄介なボトルネックになる。だからこそ、俺はGoを学ぶことにしたんだ。C/C++より高レベルだけど、Pythonよりは低レベルで、Pythonではできないことができる適切にスレッド化された(そしてグリーンスレッド化された)プログラミング言語だよ。コンパイルも理由の一つだけど、スレッドに関しては二次的な理由だね。

変化を恐れているのは君だけじゃないし、ちょっと変化に抵抗があるのも分かるよ。ここでの問題は、その恐れの理由があまり合理的じゃないってことだと思う。それに、広いコミュニティの関心は技術的負債に対処することだからね。GILは純粋な技術的負債だよ。30年前は正当化できたけど、20年前はちょっと不格好で、今では世界中がAIのデータ処理をPythonでスケールさせている中で、もううんざりで恥ずかしい存在になっている。プラットフォームの将来を見据えるためには、GILは取り除かれるべきだった。君にとって何が変わるかって?スレッドを使い始めない限り、何も変わらないよ。多分、スレッドを使ってなかったんじゃないかな。Pythonでスレッドを使う意味はほとんどないからね。ほとんどのPythonコードベースはスレッドモジュールを完全に無視して、代わりにノンブロッキングIOや非同期処理などを使っている。GILの問題は、実際にスレッドを使う場合にだけ影響してくる。スレッドを使わないなら、GILを取り除いても何も変わらないよ。壊れるコードなんてないし、スレッドセーフじゃないCライブラリもまだシングルスレッドのままだよ。今スレッドを使い始めたら、注意が必要になるだけだ。もちろん、スレッド化されたPythonコードもあって、ちょっとナイーブに書かれていて、速くなることを期待しているけど、実際にはGILに引っかかっていて、実質的にシングルスレッドになっているものもある。そのコードは今、少し速く動くかもしれないし、ナイーブなスレッドコードはバグが多いから、バグも増えるだろうね。でも、君の不安を解消するためのシンプルな解決策は、スレッドを使わないことだよ。大丈夫だよ。もしくは、スレッドの使い方を学ぶことだね。今ややっとできるようになったし、正しい抽象化があればそんなに難しくないよ。将来的にはそういうものが続々と出てくると思う。構造化された同時実行は、コミュニティの中の何人かにとっては高い優先事項だろうね。

スレッドを使うためにfork()しなきゃいけない最後の言語を使ってるなんて、きっと嬉しいだろうね。結局、消費者向けのマルチコアプロセッサが登場してから20年しか経ってないからね。

これはよくある間違いで、非常に悪く伝えられているね。GILはPythonのコードをスレッドセーフにしない。内部のCPythonの状態を保護するだけなんだ。今日のマルチスレッドのPythonコードはスレッドセーフじゃないよ。

あなた一人じゃないよ。デビッド・バロンのメモは確かに当てはまるね:https://bholley.net/blog/2015/must-be-this-tall-to-write-mul... こういう作業のために考案された言語では、思ったほど簡単じゃない。ほとんどの言語では、意味がまったくないナンセンスを書いてしまうことになる。実験によると、人間は非自明なプログラムを成功裏に理解できないことが分かっていて、Sequential Consistency(順序一貫性)を示さないと理解できないんだ。つまり、すべての出来事が特定の順序で起こるかのように理解できる必要があるんだ。これは機械の動作の現実ではないけど、そうでないと人間のプログラマーは「え、わからないな、全部コンピュータのことかな?」って感じになっちゃう。ほとんどの言語では、この要件を満たさない並行プログラムを書くのはすごく簡単だけど、デバッグしたり、何をしているのかを考えたりすることができないから、災害だよ。私の理解では、GILなしのPythonはSCを失うプログラムをもっと可能にするだろうね。

最悪のケースは、まるで「Python4」のようになるかもしれないね:人々が非GILにアップデートしようとすると壊れるから、数十年も古いバージョンのままでいることになる。

どんな依存関係を考えてたの?Pythonではいろんな呼び出しがGILを解放するから、ロックが必要だし、ほとんどの言語と同じようにレースコンディションもあるよ。JSみたいにコードが「await」するまで順番に実行されるってわけじゃないからね。GILを取り除くことの課題は完全には理解してないけど、C拡張に関することだと思ってた。ほとんどのユーザーが直接心配することじゃないと思うけど。

良いエンジニアリングデザインってのは、不均衡なトレードオフをすることなんだよね。低コストで大きなリターンを得るためにさ。こういう決断は意見が分かれることが多くて、重要なケースでたくさんの利益を得るために、いくつかのエッジケースにはノーと言わなきゃならない。俺が学んだ教訓の一つは、良いデザインは人気やそれに伴う官僚主義には耐えられないってこと。時間が経つにつれて、人々は明確に避けたケースをやれってリクエストをどんどん寄越してくるんだよね。お前が彼らの仕事を妨げていて、現実的じゃないってさ!結局、彼らのために擁護する人はいなくなる。コミュニティにはもっとリソースがあって、もう少し複雑さを受け入れられるってのも一因だけど、だからこそ俺は小さいコミュニティのツールが好きなんだ。

次のパフォーマンスの時代に向けて、これは本当に重要な基盤だね!

Hacker Newsで議論の続きを見る