Python 3.14ついに登場！気になる速度は？

パフォーマンス改善は最近始まった取り組みだよね。Luaが、インタプリタ言語でも速くできるってことを示してる。単に、これまで優先順位が高くなかったってだけ。遅いコードはCベースのモジュールで簡単に実装できたし。

うーん、優先順位だけの問題じゃないんだよね。Pythonの極めて動的な性質のせいで、言語に大幅な破壊的変更を加える覚悟がない限り、多くのことを最適化するのが本質的に難しい/不可能になるんだ。v2からv3への移行で、ほとんどの人がそうじゃないってことを痛感したと思う。

誤解しないでほしいんだけど、Pythonを高速化しようと努力してる人がいるのは素晴らしいことだけど、Pythonが抱えるレガシーコードのせいで、パフォーマンスのために設計された言語と対等に競争できるとは思わないな。

Pythonが一番好きな言語で、主にPythonで仕事をしてる（けど、他の言語もプロとして経験してる）人の意見としてね。

そうじゃなくて、Python Foundation自身が、Pythonのパフォーマンス向上を当面の目標の一つに掲げてるって言ってるんだよ。いろんな会議でも頻繁に取り上げられてるし。この目標に向けて、いくつかのイニシアチブも進められてる。GILの削除、JITコンパイルの追加、その他Python 3.11以降のパフォーマンス関連のシステム変更とかね。

JavaScriptも同じような状況だったけど、最終的には速くなったじゃん。

Pythonも最近JITを手に入れたけど、今のところは大したことない。でも、いずれは柔軟性を活かせる部分じゃなくて、実際に使ってる部分を最適化できるようになるかもしれない。

JITは、実際にどんなパターンを使ってるかを追跡して、それに最適化されたコードをコンパイルして、その前提が崩れないようにバリアを設ける。もし前提が崩れたら、別の方法を考える間、遅いコードに戻すんだ。

JavaScriptが速くなったのは、GoogleがV8を速くするために、トップレベルのエンジニアリング人材を使って莫大な金を費やしたからだ。もしどっかの巨大企業がPythonに同じような投資をして、コミュニティがそれを許可するなら、Pythonも同じように改善される可能性はある（それが可能だとしてもね。それぞれの言語が遅い理由は1対1で対応しないだろうから、Pythonの問題を解決するのがより難しいリスクもあるけど、投資なしには確信できない）。

どっかの巨大企業がPythonに同じような投資をしない限り

例えば、MicrosoftがGVRとチーム全体 を雇って、Pythonを速くすることを明確な目標にしてるとか？

それだ。最近の3.14のリリースに関する議論の中で見つけられなかったんだ。最近のMicrosoftのレイオフで、彼らが大きな打撃を受けていなければいいんだけど。

4ヶ月前にキャンセルされてるよ。

https://www.linkedin.com/posts/mdboom_its-been-a-tough-couple-of-days-microsofts-activity-7328583333536268289-p4Lp/

マジかよ、神様！お願いだから、やめてくれ！いやだー！…いやだ！いやあああああああ！

https://www.youtube.com/watch?v=umDr0mPuyQc

彼らは時間とお金を投資したけど、V8に匹敵するほどのものだとは感じなかったな。

いろんな大企業がPythonの高速化を試みてきたよね。GoogleはUnladen Swallow、DropboxはPyston、MetaはCinder、MicrosoftはFaster CPython。知ってる限り、Cinderしか残ってないけど。

実際のボトルネックはPythonコードには現れないからね。

InstagramはDjangoで動いてるよ。

DBはCで書かれてるんだね

じゃあなんでnumpyはPythonで書かれてないの？

オーケー、君は完全に僕のコメントを誤解してる...

なぜなら numpyはPythonで書かれていないから、ボトルネックはPythonには現れない。ライブラリの呼び出しを繋ぎ合わせるだけだから。その繋ぎ合わせるコードはボトルネックにならない。ボトルネックになるのはライブラリの中のコード。

JavaScriptも全く同じだよ。で、JavaScriptは速くなった。それがまさにJITのポイント。

この記事が、あなたの意見を否定してるじゃん。PyPy版はNode版と同じくらい速いんだから。

Pythonの極めて動的な性質のせいで、言語仕様に大幅な破壊的変更を加える覚悟がない限り、最適化が困難あるいは不可能になってしまうことが多い

必ずしもそうとは言い切れないぞ。

Pythonと同じくらいの重量級で、同じく動的な性質を持つMATLABを見てみろよ。何年も前にJIT（Just-In-Timeコンパイラ）が導入されたとき、劇的な改善が見られたんだ。それまで工夫してベクトル化していたコードと同じ速度で、単純なループを書いてもJITが処理してくれるようになったんだ。動的に拡張されるリストとか、他にもいろんな面でパフォーマンスが上がったしな。

https://blogs.mathworks.com/loren/2016/02/12/run-code-faster-with-the-new-matlab-execution-engine/

この差は、MATLABと互換性のあるオープンソース実装であるOctaveを比べたときにも明らかだったよ（まあ、Octaveも独自のJITに取り組んでいるのは知ってるけどね）。

現実世界のMatlabは、Pythonほどめちゃくちゃ動的じゃないんだよね。速度に影響するものの99%は、double型、double型のベクトル、double型の行列のどれか。JIT（2002年に初めて導入された！）は、インタプリタ型のMatlabがスカラーコードで_めちゃくちゃ_遅かったから、ものすごく役に立ったんだ。今ではただ遅いだけだけど、Matlabが最適なツールとなるユースケースには十分なんだよね。それでも、例えば単純なC++のコードよりも、スカラーに対して1桁か2桁遅いけど。

彼ら自身のTest1の例でもそれが示されてる：JITバージョンは1秒あたり23Mのアサインメントを処理してる。一方、ナイーブなC++のループは1秒あたり1G以上のアサインメントを処理してる。

MATLABも実際には同じくらい動的だよ。Pythonよりも「簡単なケース」だとは思わないな（クラス、演算子のオーバーロードなどがあるから、単純な c = a + b というステートメントもどちらのランタイムでも単純じゃない）。MATLABの構文は特定のこと（例えば M(x) が関数呼び出しだったり配列のインデックスだったり、メソッドのディスパッチ構文が obj.func() と func(obj) だったり）をより曖昧にするくらい。

誤解しないでほしいんだけど、数値行列を扱う典型的なユースケース（MATLABが得意とするもの）のことを言ってるんじゃないよ。それと同等の役割をPython + Numpyが果たしていて、どちらもネイティブコード（BLAS、LAPACKなど）で実装された線形代数ライブラリのラッパーとして機能してる。

僕が注目してるのは、どちらもインタプリタ型の動的言語であることと、適切なJITがどれだけパフォーマンスを大幅に向上させられるかってことなんだ。

一般的に、MATLABコードのボトルネックは関数呼び出しのオーバーヘッドから来てる。慣用的なMATLABコードは、メソッド呼び出しを減らすためにベクトル化される傾向がある。SIMD（single instruction multiple data）を考えてみて。1回の呼び出しでベクトル全体のデータを一度に処理するんだ。

だから、Test1 の実行時間は、実際には foo1 と foo2 への何百万回もの関数呼び出しのタイトなループによるもので、代入自体についてはそれほどでもない。

結果に示されているように、「新しい」JITバックエンドが有効になると、ホットスポットを認識して、それらの呼び出しをジャストインタイムで最適化した。公平を期すために言うと、このブログ記事は10年前のものだから、示されているベンチマークの数値は正確に最新のものとは言えない。彼らのJITはその後も改善され続けてるからね。

僕が言いたいのは、Pythonでもできるってこと。「言語が動的すぎる」から不可能ってことはないんだ。

たいていこういうことを言う人は、Smalltalk、SELF、Common Lispみたいな言語を使ったことがないんだよね。これらの言語も同じくらい動的で、優れたコンパイルツールチェーンを持ってるのに。

SmalltalkとSELFの場合、それらの研究が最終的にJavaとJavaScriptにおける最初のJIT実装につながったんだ。

Smalltalkでは、イメージベースのモデル（Lispでも同様のアプローチ）で、デバッガで中断してステップをやり直した後、いつでも何でも変更できる。

同様に、これらの言語はPythonと同じように、実行中にコンパイル済みのコードをその場で変更する機能を持っている。デバッガに入らなくてもね。

言語を速くできないって言ってるんじゃないんだ。広く使われてるライブラリのちょっとした部分を微妙に壊さずにそれをやるのは現実的じゃないと思ってるって言ってるんだ。言語がそういうのに適した API で設計されてれば別だけど、Python はそうじゃないんだよね。

もし劇的に改善されるとしたら、Google が JavaScript に投資したのと同じくらい Python に大企業が投資して、何年もかけて大変な努力をした結果、わずかな改善が得られる、って感じになると思う。理論的に不可能だって言ってるわけじゃないけど、言語に破壊的な変更を加えることができたら、ずっと楽になるだろうね。でもそうしたら誰も使わなくなっちゃう。

あと、パフォーマンスをそんなに気にするなら、Go とか他のもっとパフォーマンスの高い言語に乗り換えて、Python は糊付けに使う、って方が絶対コスパいいと思うよ。

[削除されました]

笑える。論理学教授気取りの弟よ、CとC++が実際どれだけ似てるか過小評価してるんじゃない？ キーワードやシンタックスレベルだけでなく、両方でコンパイルできるプログラムが、マジで全く同じコードになるんだぜ。

あとさ、俺はインフルエンサーが配信で読み上げるための意見記事を書いてるんじゃないんだ。これはPython Foundationの公言してる目標なんだよ。Python 3.11からPythonのパフォーマンス向上に取り組んでる。GILを取り除いてJITを実装したがってるのもそのため。

片方が賢くて、もう片方がアホだから、彼らはこれをやってるんだよ。

[削除されました]

基本的なことじゃないんだ。言語仕様の中核となる基礎が同じなんだよ。C++はCのスーパーセットだったんだ、C23の最近のやつまではね。言語機能と勘違いしてるのは、C++の標準ライブラリが根底にあるコードの複雑さを増しているように見えるからだよ。でもそうじゃない。Cコードと完全に互換性があるんだ。

https://stackoverflow.com/questions/2744181/how-to-call-c-function-from-c

これは、C++がCの呼び出しを特別な形式にマーシャリングしてC++コードが理解できるようにする特別なサンドボックス機能を持っているからじゃない。C++はクラスを扱うための追加機能が加わっただけの同じ言語だからだよ。だからC++はもともと「クラス付きC」と呼ばれていたんだ。Bjarne StroustrupがDennis Ritchieとの親交について頻繁に言及し、可能な限り2つのコードベース間の互換性を維持したいと考えているのは、その相互運用性が実用的で実際的な利点であるだけでなく、彼にとって感傷的な価値もあるからなんだ。

C23の最近の変更までは、C++は基本的にCのスーパーセットだった。

C++がCのスーパーセットでなくなったのはC99の時だよ。少なくともrestrict キーワードがあったからね。これはそれ自体かなり便利なんだ。

だよね。Pythonは今でも高速化がマジで難しい。たぶん、一番動的な言語の一つだから。例えば、Cの薄いラッパーみたいなもんで、何十年もマジで遅かったPHP（最近やっとパフォーマンスが改善された）とか、同じく高度に動的だけど、数十億ドル規模の企業が可能な限り最適化するためにお金を注ぎ込んでるJavaScriptと比べてみな。

パフォーマンスをめっちゃ気にする人がCPythonを使うとは思えないな

残念ながら、それは違うんだよね。みんなそう言うけど、結局Pythonを何でもかんでも仲介役に使いたがるし。

例えば、C/C++のコードをGDBかLLDBでデバッグする？おめでとう、デバッガが変数を表示する速度は、ビジュアライザースクリプトのせいでCPythonのパフォーマンスに縛られてるよ。

残念ながら、今作ってるゲームのためにね。

https://store.steampowered.com/app/3122220/Mr_Figs/

4年くらい前に選んだのが間違いだった。

今振り返ると、Defold (ゲームエンジン) か、C# か Haxe で自作するかな。

君みたいな基本的な2Dゲームなら、アニメーションやライブのグラフィック処理が大量にあるわけじゃないし、Python で全然問題ないよ。でも、必要ならコードを変換できるライブラリもあるだろうし、LLM を使うこともできるはず。労力に見合うかどうかはわからないけどね。

ああ、だいたい大丈夫だよ。ただ、リアルタイム巻き戻し機能があって、それが使える CPU を全部食い尽くすんだよね。pygame がサポートしたら、近いうちに pypy に移行したいと思ってて、そうすれば状況は良くなるはず。

ナメクジにとって、カメが「めちゃくちゃ速く」見えるのは確かだね！チーター（C++）の概念は、途方もなくありえないレベルだろうな。

もちろん、何かと比較する必要があるし、「俺たちが持ってる」のは、インタプリタ型、バイトコードにコンパイルされる型（通常は必ずGC付き）、GC付きでマシンコードにコンパイルされる型、GCなしでマシンコードにコンパイルされる型（C、Rustみたいな手動メモリ管理）っていう主要な4種類の言語だよね。（ハイブリッドもあるのは知ってる）

これは単純化しすぎだってのはわかってるけど、大体の感じは伝わるでしょ。

速度は相対的なんだよね。ボトルネックにならない程度に速ければ十分ってことが多い。

書き換えはリスクもコストもかかるし、言語の切り替えはさらに大変。

速度の改善は、もっと速い選択肢があったとしても価値がある。

既存のコードの多くは CPython で動いてるし、パフォーマンスが向上すれば、寿命が延びたり、ローエンドのハードウェアをサポートできたりするかもしれないしね。

落ち着け

JITだね。

特殊化JITコンパイラ。

Pythonの実行で一番コストがかかるのは、どんな操作なのかをまず特定する必要があるってこと。

例えば a = b + c は実際にはこんな感じに実行される:

• bは動的に型付けされたオブジェクト (PyObject *)
• オブジェクト内のポインタからbの型をロード。bはint型だと判明。
• int型オブジェクトから、__add__メソッドのポインタをロード。
• __add__メソッドを実行。これは以下の処理をする:
• cの型をチェック
• cがint型でなければ、cから型オブジェクトをロードし、そこから__int__メソッドをロード
• それを実行してintオブジェクトを取得 (または例外)
• 実際の整数加算を実行 (Pythonの整数は任意精度なので、オーバーフローの可能性をチェックする必要があることに注意)。
• 結果のために新しいPyObjectを割り当てる。
• それを返す

そして、まだ多くのことを無視してる。例えば、__radd__も存在すること、異なる型ルールが適用される可能性があること、サブクラスに対して発生する可能性のあるクラス解決など。

これらはすべて実行時に行われる。これはかなり遅いけど、柔軟でもある。

PyPyが行うのは、以下のようなこと:

• このメソッドは通常、引数がint型で呼び出されるよね。

• 引数がint型かどうかを最初にチェックし、そうであれば実行時の型チェックをすべてスキップして加算だけを行うバージョンの関数をコンパイルしたらどうだろう。

• そして、何か問題が発生した場合 (オーバーフローやエラーなど) は、遅いインタプリタ版にフォールバックする。

ほとんどのプログラムの時間の大部分は、ごく一部の関数で費やされ、それらの関数は通常、同じ型の引数で呼び出されることがわかる。したがって、このようなアプローチは多くの時間を節約できる可能性がある。

これは非常に単純化された説明で、PyPyがこの効果を達成する実際の方法は奇妙だ。本質的にPyPyは実際のJITコンパイラですらなく、インタプリタを入力として受け取り、そのインタプリタからJITコンパイラを作成するアルゴリズムなんだ。そして、それがPythonインタプリタ上で実行されて最終的なものが作成される。

c が int でない場合、c から型オブジェクトをロードし、そこから int メソッドをロードする

ここ間違ってるよ。整数加算で暗黙的な変換はないから。

やってることは、b の __add__ メソッドを試して、NotImplemented を返したら c の __radd__ メソッドを試してるんだよ。（君が言ってるようにね）

class A:
    def __radd__(self, other) -> int:
     return other + 5
  
print(3 + A())  # 8

class A:
    def __int__(self, other) -> int:
     return other + 5
  
print(3 + A())  # TypeError: unsupported operand type(s) for +: 'int' and 'A'

ごめん、会話ルールを勘違いしてたわ。

ま、いずれにせよ、肝心なのは、毎回足し算するたびに、これを全部実行時に解決しなきゃいけないってこと。

そうそう、今年の EuroPython で PyPy のメンテナーがまさにそれについて講演してたよ。

で、そのせいで、JIT コンパイラでさえできることには限界があるんだよね。どこかでチェックが必要になるから。

πthon（パイソン）

めっちゃスクロールさせられたわ。

マジでそれな。

Pythonが遅いことを考えると、大規模なnに対しては、ほとんどすべての非自明なアルゴリズムがこの基準を満たすと思うよ。numpyみたいなライブラリがコンパイルされたコードのラッパーに過ぎないのには理由があるんだ。

どの言語でも遅いコードを書くことはできるけど、速いコードを書けるとは限らないよね。

OK、じゃあ0 で遅いコードを書いてみてよ。

うちの会社じゃ、Pythonで書かれたサービスをGoに単純に置き換えるだけで、パフォーマンスと密度（同じリクエスト数に対して必要なサーバー数）が大幅に向上するのをよく見るよ。結局、何度も同じことを繰り返すと、その差が積み重なるんだよね。

何かをたくさんやると、違いが積み重なるってことか。

マジかよ。

シンプルで高速なビジネスロジックをたくさん書けたとしても、複合的な影響でレイテンシーの問題は発生するよ。それに、デシリアライズ/シリアライズも大きな悩みの種。巨大で複雑なプログラムを構築して、大量のデータ相互運用をするには、メモリ/CPUのオーバーヘッドを可能な限り最小限に抑える言語/プラットフォームが必要なんだ。残念ながら、Pythonは古いモノリスプロジェクトには向いてないね。

何十億ものユーザーにスケールするサービスを扱ったことのない人だね。

えーと… InstagramはPythonで書かれてるよ。（でも、念のため言っとくけど、OPの言ってることはやっぱり間違ってるよ。）

GPUでできることなら何でも。でも、すべての言語が効率的に（あるいは全く）そこで実行できるわけじゃない。

研究で木探索アルゴリズムを書いてるんだけど、C++に移行すると、速度が桁違いに向上するよ（実際にそうしてる）。

EUの交通情報に関するNeTExのxmlファイルをPythonで解析するのはかなり遅いんだよね。でも、NeTExの信じられないほど複雑なxsdに対応できる、十分に優れたxsd genライブラリがある言語って、Pythonくらいしかないんだよ。

スレッド化が必要なCPUバウンドなコード全般だね。でも、それが常に問題ってわけじゃない。ほとんどの場合、問題はメモリの割り当てと解放、ミッションクリティカルなサービスの起動時間の遅さ、などなど。

みんな知らないかもしれないけど、メモリはどんどん遅くなってるんだよね（アクセス時間とクロックサイクル比で）。速くなってるんじゃなくて。

でも、キャッシュフレンドリーなコードの書き方は、あんまり教えられてないし、すべてが辞書みたいな言語じゃ、そもそも無理があるんだよね。

Import-CSV myFile.csv

これをどうにかして改善しようとしたら、C#を使うことになるだろうね。PowerShellは遅いから。

そもそも、ありえない主張に対する、ありえない例だよ。

どうぞ - https://programming-language-benchmarks.vercel.app/

その他色々 https://benchmarksgame-team.pages.debian.net/benchmarksgame/

車のABSとESCみたいなもんかな。

例はいくつ欲しいんだ？何千個でも挙げられるよ。これらをPythonで再実装したら、言語自体がボトルネックになるだろうね:

https://github.com/torvalds/linux

https://github.com/pytorch/pytorch

https://github.com/mozilla-firefox/firefox

https://github.com/mooman219/fontdue

うわー、Pythonで書き直されたLinuxカーネルを想像したら鳥肌が立った、マジで。

面白いね：最初は20個の賛成票があったのに、どんどん減っていった 😂

これは素朴で最適化されてないシングルスレッドの#8プログラムを、一行ずつ文字通り 同じオリジナルから色んなプログラミング言語に書き換えたものだよ。

そう、C拡張との完全な互換性がないんだよね。それがPythonライブラリのエコシステムにおいて大きな部分を占めてるから。あと、しばらくの間はPythonのメインブランチに遅れをとってたけど、最近はそうでもないかな。

3.11って結構古いよね、正確には3年前か。いつも疑問に思うんだけど、リリースごとにCPythonの変更やstdlibの変更はたくさんあるけど、コアな言語自体はそんなに変わってないじゃん？ なのに、なんで3年も遅れてるんだろ？ ちゃんとメンテナンスされてないように見えるだけなのかな？ 真相はどうなんだろうね。

PyPyのメンテナーだけど、まず人数が5人以下なんだ。CPythonは何十人もコントリビューターがいるのに。次に、各バージョンでインタープリターに多くの内部的な変更があって、それをCからPythonに変換する必要がある。そして、stdlibの変更も頻繁にあって、C拡張の中にあったりして、それもPythonに変換しなきゃいけない。例えば、3.12ではf文字列のパース、デバッグの型付けやデコレーター周りの新しい構文とか、色々と大幅な変更が入ってる。これ全部、報われない作業が多くて大変なんだよね。

素晴らしい仕事に感謝します。PyPyへのサポートがもっとあればいいのにと思います。何度か試してみたけど、自分のデータサイエンスのユースケースでは、Numbaを使ったCPythonの方が良かったんだ。でも、自分が公開してるライブラリの一つでPyPy wheelsを作ってるよ。誰も使ってるか分からないけど。

洞察をありがとう。あなたの仕事に感謝します。特に、報われないことが多い仕事をしてることについて、共感します。

ありがとう、特にf文字列に関する洞察は素晴らしいね。確かにその変更（確か再帰的な文字列を許可したりとか？）があったのを思い出したけど、すっかり忘れてたよ。

いつもご苦労様です！感謝しても感謝しきれないよ！

CPythonチームがPyPyと比較してJITによるパフォーマンス向上をなかなか達成できない理由について、どう思う？

明らかにPyPyの方が成熟してるけど、それにしてもCPythonのJITの開発は遅すぎる。彼らはいつか急速に進歩するための基礎を築いているだけなのか、それとも何年もかかる非常に遅いプロセスになるのか？

PyPyは2003年頃にJIT技術の探求を開始し、7年後の2010年頃に軌道に乗った。JITの書き方を理解するにはかなりの時間がかかるし、ヒューリスティクスの調整にも時間がかかる (PyPyはこの部分を終えられなかったとも言える)。Antonio Cunioは最近、CPythonコア開発者スプリントでのプレゼンテーションで、トリッキーな部分のいくつかについて書いている https://antocuni.eu/2025/09/24/tracing-jits-in-the-real-world--cpython-core-dev-sprint/

CPython のメンテナーはなんで協力しないんだ？ PyPy はピュア Python で信じられないくらい高速化するし、Python のデフォルトになるべきだろ。

3年は古くはないね。

無料でパフォーマンスが向上したり、便利な機能が手に入ったりする機会が3回あるってことだね。そのうち2回は（3.14が出たばかりだから）ほとんどのユーザーがすでに経験済みだろう。インタープリターを変えるためには、それを諦めないといけない。

PyPyは純粋なPythonコードでのみ実行できるから、Cとか別のコンパイル言語で作られたライブラリは動かないんだ。他にも非互換性はあるけど、これが一番大きな理由。

あと、アップデートのリリースも遅いから、PyPyのコードは常に少しバージョンが遅れてる。

それに、JITは最適化とコンパイルのためにコードを数回実行する必要があるって問題もある。だから、1、2回実行してすぐに終わるような小さなスクリプトは、普通のPythonよりもPyPyの方が逆に遅くなるんだ。

今はJITを標準のPythonに取り入れようとしてるけど、互換性を損なわずにやるから、実現には時間がかかるだろうね。

それは理にかなってるね。CとかFortranを呼び出す依存関係なしにPythonを実行してる人なんて、いるのかどうか。

もうそうじゃないんじゃないかな？しばらく使ってないけど、C拡張をサポートしてるって言ってるよ。完全じゃないかもしれないし、遅いかもしれないけど: https://doc.pypy.org/en/latest/faq.html#do-c-extension-modules-work-with-pypy

ピュアなPythonコードでのみ実行できる

それは絶対に違う！

https://doc.pypy.org/en/latest/faq.html#do-c-extension-modules-work-with-pypy

PyPyはCPythonのC APIを使えるけど、PythonからCに移行するたびに、渡されるオブジェクトをCで再作成して同期する必要があるから遅くなるんだ。それに、JITはCコードの中を見れないし。多くのデータアプリケーションでは、Pythonがパフォーマンスのボトルネックになることはないんだよね。処理時間のほとんどは、NumPy、PyTorch、pandasで費やされてて、これらは全部C/C++を活用して重い処理をやってるから。

それならTeXみたいなバージョン番号の付け方に変えないとね

ハードウェアを同等にしようとしてるわけじゃないから、これらのシステム間の比較は意味ないよね。

syscallをほとんどしてないし、パフォーマンスは同じになるはず。

テストでは2つの異なるラップトップが使われたんだね。

2台のコンピュータ

• Ubuntu Linux 24.04 (Intel Core i5 CPU) を搭載したFrameworkラップトップ
• macOS Sequoia (M2 CPU) を搭載したMacラップトップ

pithonっていう実行ファイルを追加することも検討されたけど、長期的なメンテナンスの負担を考えて却下されたらしいよ。

でも、このリリースのためだけに πthon ってのがあるはず。

いや、これしかないんだ: idle3, idle3.14, pip, pip3, pip3.14, pydoc3, pydoc3.14, python, python3, python3-config, python3.14, python3.14-config

でも、シンボリックリンクは自分で作れるよ。

あらら ;(

じゃあ、これ はいつの間にか元に戻されたか、削除されたんだね。

いや、違うな。まだあるみたい: https://github.com/python/cpython/blob/3.14/Lib/venv/__init__.py#L319

俺の場合は動くよ:

:/mnt/d/Programming/Projects/Testing$ uv run --python 3.14 python -m venv pivenv
:/mnt/d/Programming/Projects/Testing$ ls pivenv/bin/
Activate.ps1  activate  activate.csh  activate.fish  pip  pip3  pip3.14  python  python3  python3.14  𝜋thon
:/mnt/d/Programming/Projects/Testing$ pivenv/bin/𝜋thon
Python 3.14.0rc2 (main, Aug 28 2025, 17:07:51) [Clang 20.1.4 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

ちゃんとリリースされてるバージョンでも動くよ:

name@PC:/mnt/d/Programming/Projects/Testing$ uv python upgrade 3.14
warning: `uv python upgrade` は実験的な機能だから、予告なしに変更されるかも。警告を消すには `--preview-features python-upgrade` を渡してね
Installed Python 3.14.0 in 1.98s
+ cpython-3.14.0-linux-x86_64-gnu
name@PC:/mnt/d/Programming/Projects/Testing$ uv run --python 3.14 python -m venv pivenv
name@PC:/mnt/d/Programming/Projects/Testing$ ls pivenv/bin/
Activate.ps1  activate  activate.csh  activate.fish  pip  pip3  pip3.14  python  python3  python3.14  𝜋thon
name@PC:/mnt/d/Programming/Projects/Testing$ pivenv/bin/𝜋thon
Python 3.14.0 (main, Oct  7 2025, 15:35:21) [Clang 20.1.4 ] on linux
Type "help", "copyright", "credits" or "license" for more information.

自分の環境では動く:

uvが出力したものしか見てなかったから、自分は動かなかったんだな。

うん、ただ"uv venv"ってやるだけでも自分はうまくいかなかった。

マジかよ…

当時としては画期的な研究で、RPythonは最新バージョンのPython 2.7をベースにしていた。2010年頃には多くの論文が発表されたよ。

GraalVMを見てみて。MaximeVMやJikesRVMみたいな研究プロジェクトから生まれたもので、似たようなアイデアを持ってるよ。

ああ、そうだ！今まで気付かなかったけど、アーキテクチャが似てるんだね。そうじゃないと、同じエンジン内でたくさんの言語をJITコンパイルするのはめちゃくちゃ難しいだろうし。

このバージョンには無限の可能性があるね。

まあ、絵に描いた餅だって言う人もいるだろうけど。