GILがなくなるなんて思ってもみなかったけど、今ここにいるよね。何事も可能性はゼロじゃない。もしかしたらPython4は別のコンパイラを使ったPythonかもね。

JS/TSの話がよくわからないんだけど、TSは単なる型チェッカーで、ランタイムパフォーマンスには全く影響しないよね。

コードを書くのが楽しいからだよ。全てがスケールする必要も速くある必要もないし。個人的には、99%の時間を最適化して1%のために使うのがもっとクレイジーだと思う。

確実に言えるのは、一銭も払ったことがないってこと。君は？

コンピュータは、プログラミングを始めた頃の100倍以上速くなってるし、その頃ですでに十分速かったんだよね。（その間に自分のコーディング能力はあまり良くなってないし、むしろ悪くなってるかも）

1%なんて全然足りないよ。pytestやPydanticみたいなよく使われるライブラリが成り立つのはそのおかげなんだから。

多くの人がSmalltalkやCommon Lisp、Self、Dylanを使ったことがないから、CPythonが唯一の選択肢だと思ってるんだよね。それに、Electronアプリでリソースを無駄にしてるから、CPythonのパフォーマンスについて疑問を持つこともほとんどない。

そうじゃないよ。Pythonには向いてないことがたくさんある。ただ、ずっと前から存在してるし、サイバーセキュリティみたいな影響力のあるニッチな分野では、Pythonはネイティブツールよりも役立つこともあるし、複数のプラットフォームで動くからね。

大抵の場合、待ってるのは人間か、少なくともCPU以外の何かだよね。プログラマーがコードを書くのにかかる時間の方が、全ユーザーがプログラムが動くのを待つ時間よりも長いことが多い。だから、これら二つの間では、パフォーマンスは大抵トレードオフしても問題ないよ。

コードが正しくないなら、パフォーマンスは無意味だよ。簡単なケースでは、Pythonで正しいコードを書くのが比較的早いし（整数はCのようにオーバーフローしないし、C#のようにラップアラウンドもしないし、他のスクリプト言語のような馬鹿げた暗黙の変換もない）。また、ほとんどの場合、コードが速くある必要はない。たまに人間が実行する数値計算が必要なだけなら、1秒かかっても大丈夫だよ。シェルスクリプトの代わりにもかなり良い。

これを知ってる人は、これが良いトレードオフだとは思ってないと思う。もっと興味深いのは、そもそもなぜそのトレードオフが行われたのかってことだよね。答えは、私たちがこれらの設計決定の影響を理解するのが比較的簡単だから。過去20年以上のPythonの結果を見てきたからね。後知恵は20/20だよ。Pythonは1991年にリリースされたんだから、Javaよりも前だし。当時のプログラミングに関する知識と、今の知識は全然違うよね。あ、あと、こういうトレードオフは一般的に作るのがすごく難しいんだ。あなたがその時は関係ないと思っていた設計決定が、後でパフォーマンスにとって重要になることもあるけど、その時点では互換性のために設計が固定されちゃってるんだよね。

主な問題は、最適化が無邪気な変更によって静かに失敗して、突然パフォーマンスが10倍落ちることだよ。これはどの言語でも問題だけど（CPUキャッシュミスはあるし、非動的言語でもボックス化されたオブジェクトがあるからね）、PythonやJS、Rubyのような動的言語ではもっとひどい。大抵の場合は問題にならないけど、高スループットのPythonコードはC/C++を呼び出すことが多いから、そういう懸念はあまり大きくない。ほとんどのJSコードもC/C++のブラウザDOMオブジェクトを呼び出すだけだし。ホットパスがこれらの言語にない限り、「無邪気な変更でパフォーマンスが落ちる」リスクはそんなに高くない。サーバーサイドでも、ほとんどのJS/Python/RubyコードはシンプルなHTTPスタックハンドラーやデータベースを呼び出してデータをやり取りしてるだけだからね。リクエスト処理の大部分（JSON/XMLなどのエンコード、HTTPメッセージのパースなど）は、低レベルの言語で書けることが多い。

ちょっと軽い感じで言うと、LispマシンのCISCサポート言語のフルスタック設計哲学は、MシリーズのリオーダーバッファやILPがJavaScriptCoreをサポートしているところに生き続けていると言えるね。

そういうわけで、絶対的に見れば、Pythonは思ったほど遅くないんだよね。でも、プログラミング言語のパフォーマンスは絶対的に測るものじゃない。一般的にはCに対して相対的に測るんだ。で、君のPythonコードがこのPythonオブジェクトがどうアンボックスされるか、メソッドがどこにあるか、パラメータをどうアンボックスするか、どのメソッドが呼ばれるかを推測している間に、コンパイルされたコードはプログラマーが書いた実際のコードを推測して並行して実行してる。だから、Pythonインタープリターが実際のオブジェクトでメソッド呼び出しがどう解決されるかを推測し終わる頃には、コンパイルされたコードは同じ文法の複雑さのコードを約50行終わらせてる。これはちょっと雑な表現だけど、PythonとCの「p.x = y」レベルのステートメントを比較してるってことね。これを避ける方法はないよ。君はその素晴らしく能力のある推測並列CPUをPythonの解釈に使うか、実際の作業に使うかのどちらかしかできない。両方は無理だよ。結局、インタープリターもCコードだからね。特別な推測オペコードにアクセスできるわけじゃない。

JSはプロトタイプの変更をサポートしているけど、最適化を難しくするwith演算子や他の構文は、典型的なJSコードでは使われていない。だからJITは、問題のある構文の存在をチェックして遅いパスに誘導しつつ、特に大きくない一般的なパターンを最適化するためのチェックを追加できる。そして、JSのJITは、ブラウザの内部がJITのニーズに合わせて調整/リファクタリングできるので、任意のネイティブコードを呼び出すことについてあまり気にする必要がない。Pythonではそれがうまくいかない。最適化に優しくない構文が単純に多くて、人気のあるライブラリがそれを使っているから。さらに、Pythonは固定ABIの任意のCライブラリを呼び出すから、Pythonの最適化は本質的に難しいんだ。

でも、v8は一般的なユースケースをすごく速くしてくれたよね。Pythonの未来が楽しみだな。v8はまだ完全にシングルスレッドで、メッセージパッシングも限られてるんじゃない？Pythonはマルチスレッドのコードを速くするためにたくさんの作業をしたばかりなのに、もしスレッドを完全に捨てて、v8に合わせるために共有メモリでマルチプロセッシングに戻ることになったら、がっかりだよね。

ブランチ予測が、ハッピーパスのチェックが大きく/複雑になるときにパフォーマンスの損失を隠せるのか気になるな。ブランチ予測は非常に低レベルの最適化だし、予測が正しければすべてが無料になるわけじゃない。CPUは条件を評価しなきゃいけないから、リソースを使うんだよね。とはいえ、それがクリティカルパスから外れてるのは確かだけど。条件の実行よりも先に進みすぎると、CPUがスタックすると思うんだ。結局、プログラムが完了するまでにはすべてのコードが実行されなきゃいけないから。Pythonの特性を考えると、チェックがすごく複雑になって、タイトなループではリソースにかなりの圧力をかけるかもしれないね。

そうそう、これでPythonが遅い理由が全部確認できた気がする。スクリプトを超える用途には向いてないと思う。毎日使ってるけど、mypyみたいなツールも信頼できないことが分かった。隅々まで考慮されてないケースが多すぎるからね。言語に明確な型設計がないと、外部ツールで根本的に解決できるわけじゃない。テストだけが、この言語で書かれたコードを信頼できる唯一の手段だよ。

記事をもっと注意深く読む必要があるよ。最初の神話は「Pythonは遅くない」ってやつで、これは打ち消されてる。遅いからね。次の神話は「ただのグルー言語で、ホットパーツをC/C++で書き直せばいい」ってやつで、これも打ち消されてる。C/Rustで書き直すだけじゃ解決しないんだ。三つ目の神話は「Pythonはインタプリタだから遅い」ってやつで、これも打ち消されてる。インタプリタだから遅いわけじゃないんだよ。

これは、ループ内で同じ操作を繰り返すことを取り出す一般的なルールの具体例じゃない？ CPythonでCへの呼び出しが特に遅いかどうかは疑問だな（多くの操作は実際にはCを呼び出してるだけだし）。

境界を越えるのがどれだけ非効率的か 99.99%のプログラムに関して言えば、現代のM.2 NVMEハードドライブは十分速いし、C拡張やプロセスにデータを読み込むための一番楽な方法なんだ。それに、Unixパイプも十分速いよね。共有メモリもあって、基本的に読み込みがないからね。Pythonの場合、すべてはセットアップ次第だよ。

最近は「Rustで書き直し」って感じだよね。通常、Pythonは入り口と出口のポイント（ちょっと手を加える程度）でしょ？それからビジネスロジックの大部分はRust/C++/Fortranで処理されるんじゃない？

Pythonを「グルー言語」として使う一例で、実際にバインディングのパフォーマンス問題を避けられるのはGNU Radioだね。これは、基本的にPythonを設定言語として使って、スタートアップ時に計算フローグラフをセットアップするからで、その後の実行時は完全にコンパイルされたコード（一般的にはC++）で動くんだ。もちろん、このアプローチはすべての問題に適用できるわけじゃないけど、遅いグルー言語が受け入れられる場面についての考え方を大きく変えたよ。

効率の悪さだけじゃないよね。PyO3やSWIGみたいな高機能なFFIジェネレーターを使っても、FFIを追加するのはめっちゃ手間がかかるし、複雑になるし、デバッグも難しくなるし、配布も大変になる。個人的には、FFIを使って二つの言語でプロジェクトを書く場合は、通常は一つの言語だけでやった方がいいと思う。たとえその言語が最適じゃなくてもね。この場合は、全部C++（かRust）で書いちゃえばいいんじゃないかな。例外もあるけど、一般的にFFIは大きなコストで、C++を使ってるならPythonを使う理由はあまりないと思う。

前の段落は、>「もう一つの『神話』は、Pythonが遅いのは解釈されているからだ。確かにその通りな部分もあるが、解釈はPythonが遅くなる要因のほんの一部に過ぎない。」彼は遅いことを認めているけど、解釈されていることとは関係ないと言っているんだ。

「十分に賢いコンパイラ」は、Pythonのセマンティクスを合法的にスキップできないんだ。Pythonでは、p.x * 2は動的なルックアップや、可能なディスクリプタ、大きな整数のオーバーフローチェックなどを意味する。コンパイラがそれを省略できるのは、重要でないことを証明するか、推測してガードを追加する場合だけなんだけど、それでもオーバーヘッドが発生する。だから、Pythonはスカラーのホットループで遅くなるんだ。解釈されているからじゃなくて、動的な契約を守らなきゃいけないからなんだよね。

この議論の問題点は、ユーザーがそういうことをしようとしていないってことだ。俺はちょっと違う意見を持ってる。問題はユーザーがそういうことをしているわけじゃなくて、言語が彼が何をしようとしているかを理解していないことだ。Pythonの明確な目標は常に使いやすさで、スピードや面倒なコンパイルエラーメッセージよりも使いやすさが優先されていた。「書かれた通りにコードを実行しろ、くそ！」が常に目指していたことだ。クラスモデルが導入されたとき、__get_attribute__の導入が必要になったことを覚えている。Cプログラマーとしての最初の反応は「おお、そこは速度が落ちるね」だった。その後の反応は、新しいシステムを発明者が考えもしなかったような形にねじ曲げるために使うことだった。それはLR(1)パーサーで、文法を通常のPython文として書けるようにしてくれた。彼らが特定の方法で言語を悪用することを考えていなかったかもしれないが、明確な目標は最小限のコードであらゆるアイデアを表現できるフレームワークを作ることだったと思う。他の人たちも、言語の構築方法に提供されたフックを使って、pydanticやspyneのようなものを作っていた。例えば、SpyneはRPCで使われる通信フォーマットをPythonのクラス宣言として表現でき、それをJSONやXML、SOAPなどにコンパイルできる。SqlalchemyはPythonの構文を使ってSQLを表現できるが、もっとストレートな方法だ。どれも言語をうまくねじ曲げているよね。そのフレームワークの中では、「a = b + c」は「bをcに足して、その結果をaに置く」って意味じゃない。例えばLR(1)パーサーでは「'a'という生成物があって、それは'b'の後に'c'が続く」って意味だ。その定義の中で'a'は'b'と'c'への参照を持っている。後でLR(1)パーサーはそれを消費して、全く違うものにコンパイルする。結果は2の補数加算とは大きく異なる。強力な型システムを同じように使うことも可能だ。例えば、Scalarで表現されたFPGA設計を見たことがある。しかし、Scalarの型システムはコンパイル時に何が起こっているかを知ることを要求するので、Scalarはプログラマーが何を作っているかをある程度把握している。コンパイル結果は他のコードと比べて遅くなることはないだろう。Pythonはコンパイル時の型チェックをほぼ完全に放棄することで同じ柔軟性を達成し、すべてをランタイムに押し込んだ。だから、コンパイラーは最終的に何が実行されるかを全く知らない（例えば、LRパーサーでの+操作は一度だけ実行される）。これが俺が言った「言語がプログラマーが何をしようとしているかを知らない」ってことだ。お前は、インタープリター言語だから、インタープリターがランタイムでプログラマーが何をしようとしているかを理解する役割を持つべきだと言っている。確かに「a = b + c」が実際にはオーバーフローしない32ビット整数を加算していることは理解できる。でも、それはランタイムでやるべき仕事が増えるってことだ。これは、同じことを言い換えた形で、話の内容と同じことだ：ランタイムでやることを選ぶってことは、言語がスピードよりも柔軟性を選んだってことだ。インタープリターでこれを常に修正することはできない。Javascriptには最高のインタープリターがあって、ハッピーパスを速く実行することができる。でも、そういうインタープリターには注意点があって、通常は「クラスの内部をいじると、例えばランタイムで関数定義を置き換えると、JITの試みをすべて放棄する」って形だ。人々は通常Javascriptでそんなことをしないけど、実際にはPythonのデザインはメタクラスや「type(...)」、そして「new(..)」を使って、そういうコーディングスタイルを奨励していると言えるかもしれない。つまり、これもまた言語設計の選択で、スピードよりも柔軟性を重視するものなんだ。

Python 4.0の良い例かな？最終的にはこれに同意するけど、今は開発者がオブジェクトにdynamic=Falseを設定して、オプトインにするだけでいいんじゃない？これがGoogleがAngularの破壊的アップグレードを扱う方法で、実際には人々が数年かけて破壊的な変更に備えることができるから、うまくいってるんだよね。

Python 4.0の良い例かな？「Python 4.0」は、実質的には別のチームによって作られた新しい言語になると思うけど、強い文法的な類似性があるだけなんだよね。（それがまだ実現していない理由の一部は、みんなそのタスクのスケールにビビっちゃってるからだと思う。）Juliaをチェックするのを忘れてたことを思い出させてくれてありがとう。

Juliaがパッケージマネージャーの問題を解決したら（インポートの読み込みにまだ時間がかかるのかな？）、人気が出ると思う。

そうだね、これは「用途に応じた馬」ってやつだね。Pythonが大好きだよ。uvとの相性が最高で、今朝はデータを分析するためのシンプルなCLIを実装したんだけど、インライン依存関係があって、必要なものにぴったりで、書くのも実行するのも調整するのもめっちゃ簡単だった。過去の経験から言うと、パフォーマンス（レイテンシーやスループット）やリクエストのスケーラビリティが問題になるAPIサーバーにはPythonを使うべきじゃないと思う。そういうのには他に素晴らしいツールがたくさんあるからね。もしAPIサーバーを書く必要があって、超高パフォーマンスじゃなくても大丈夫なら、Pythonはそれにも向いてるよ。でも、Pythonにはそれに合った良さがある。もしPython 4.0がいくつかの破壊的な変更を伴うものになったら、Pydanticみたいなものが引き続き動くように、インタープリタの特性を保ってほしいな。

このコメント、LLMが書いたのかな？