Pythonコンパイラ「Codon」誕生 72
ストーリー by nagazou
両立 部門より
両立 部門より
Pythonは可読性や広範なエコシステムなどから、最も人気のあるプログラミング言語だが、速度面での評価は高くない。そんな中、MITの研究者たちは高級言語の親しみやすさと低水準言語の高速性を両立させる方法を発見したという（The Register）。
彼らは「Codon」と呼ばれるPythonコンパイラを開発し、Pythonコードをネイティブなマシン語に変換することで、実行時のパフォーマンスを低下させないようにすることに成功したそうだ。レポートによれば、Codon使用時のパフォーマンスは、シングルスレッド性能で従来の10-100倍以上の高速化を達成している。C／C++と同等もしくはそれ以上の性能があるとしている。
もっとも課題も残っているという。CodonはPythonのほとんどの機能を実装しているが未実装の部分も残っていたり、Pythonのモジュールの中にはCodonに組み込まれていないものもある。このほか、コードの解析や最適化を難しくする機能も省かれているという。
彼らは「Codon」と呼ばれるPythonコンパイラを開発し、Pythonコードをネイティブなマシン語に変換することで、実行時のパフォーマンスを低下させないようにすることに成功したそうだ。レポートによれば、Codon使用時のパフォーマンスは、シングルスレッド性能で従来の10-100倍以上の高速化を達成している。C／C++と同等もしくはそれ以上の性能があるとしている。
もっとも課題も残っているという。CodonはPythonのほとんどの機能を実装しているが未実装の部分も残っていたり、Pythonのモジュールの中にはCodonに組み込まれていないものもある。このほか、コードの解析や最適化を難しくする機能も省かれているという。
シングルスレッド性能もそうだけど・・・ (スコア:2)
Re: (スコア:0)
簡単に並列化できるようにならないかな？
Pythonが八岐大蛇かヒュドラかギドラにクラスチェンジですね
Re: (スコア:0)
Orochiとかガイジンに受けそうじゃん。それいこ。
Re: (スコア:0)
GILの制約はどうなってんだろ
Unicodeが使えないとなると、使い道が厳しい (スコア:1)
日本語が標準で使えないじゃないかよ。
自作スクリプトのほとんどを置き換えられないよ。
アメリカ人からみたら、ASCII以外を使うのは不要なオーバーヘッドにしか見えないんだろうけど。
Re: (スコア:0)
> Unicodeが使えないとなると
これ、どこの情報ですか？
Re:Unicodeが使えないとなると、使い道が厳しい (スコア:2, 参考になる)
Strings: Codon currently uses ASCII strings unlike Python's unicode strings.
https://docs.exaloop.io/codon/general/differences [exaloop.io]
Re: (スコア:0)
今時ASCIIに限定する意味が分からん
UTF-8も駄目なのか
Re: (スコア:0)
Unicode文字列の処理はかなり面倒なので後回しにしたんでしょ。UTF-8は入出力のエンコーディングであって、内部では別の表現になっている。
Re: (スコア:0)
Unicode自体がだいぶスジの悪い多言語対応なのよね、いったい実装上いくらあれば十分なんだ？
UTF-16なら十分か？UTF-32か？UTF-65536か？
将来において太陽系外惑星と接触したときのことまで考えられているのか？
Unicode、UTF系だから安心だと考えるその精神構造がまず理解できない
Re: (スコア:0)
太陽系外惑星と接触したときには地球人が思いつかなかった、あっと驚く基礎的なテクノロジーに出会うと思う。
どうしてそれを思いつかなかったのか？くやしい！っていうレベルの。
Re: (スコア:0)
内部でも単なる8ビットバイト列として扱っていて文字の途中で平然とぶった切ってくる手抜き実装も普通にあるけどな
Re: (スコア:0)
Unicode(UTF-8のこと？)を処理するためのライブラリをpythonで誰か実装しないかなー？（そういうのってクラスで解決するのかな？）
生成物はthreaded code (スコア:1)
C／C++と同等もしくはそれ以上の性能 (スコア:0)
ネイティブなマシン語なら当たり前だよね？
あとは最適化とかライブラリの出来次第。
実際には多少遅くとも同等扱いなんでしょ。
Re:C／C++と同等もしくはそれ以上の性能 (スコア:5, すばらしい洞察)
> ネイティブなマシン語なら当たり前だよね？
それは良くある勘違いです．当たり前ではありません．
C/C++のコードに比べるとpythonのコードはコンパイル＆最適化が難しいです．
難しい理由の一つは，pythonは実行するまで変数の型が決まらないためです．これはネイティブなマシン語を吐くだけでは全く解決できない問題です．
C/C++ふうに言えば，pythonでソースコード中に foo(x) という関数呼び出しがあった場合
xの型はint型，unsigned int型，float型，std::string型，struct X，class Y，など無限の可能性があります．
当然実行時には型の候補は有限で，実際の型は実行時には一つになります，ただし実行されるたびに型が変わる場合もあります．
だからpythonインタプリタは実行時に毎回型チェックをやって，その都度CPUが実行するコードを切り替えています．
ですから，仮に全パターンのマシン語を生成して，それを実行時に切り替えたところで，CPUの命令キャッシュがぐちゃぐちゃになるだけで何も問題は解決しません．
これは実行時の問題なので，実行時コンパイル（JIT）を使わないと解決できません．
つまり直接マシン語を吐く古典的方法ではなく，バイトコードをはいてバイトコードを効率よく実行する仕組みを別途用意する現代的方法で解決します．
しかしまだその技術は確立されていません．だから現状のpythonは実行速度はまだ遅く，高速化の研究が盛んに行われているのです．
言い換えると，まだ当たり前の域には到達してないから，python の処理系には伸びしろがあります．
たとえば2022年10月にリリースされたPython 3.11は 3.10に比べて10～60％高速になってます．
3.11の高速化はまさに上記のバイトコードを効率よく実行する仕組みの改良で
https://github.com/markshannon/faster-cpython [github.com] の成果です．このプロジェクトの中の人たちも，まだ伸びしろがあると言っています．
ここで注意すべきは，pythonはバージョンが3.11まで進んでるのに，これからも性能向上が見込める点です．それくらい今のpython処理系はクソなのです．
Re: (スコア:0)
>それくらい今のpython処理系はクソなのです．
処理系というか、言語仕様からの"実行"の難しさだよね。
それを分かったうえで、木に竹を接ぐようなことをしている。
やっている連中は面白いからやっているのだろうけど、
まったく筋が悪いことをやっているような気がするけど
x86アーキテクチャと同じでそこにニーズがあるからやっていられるんだろうなぁ
こんなこと
まあ、袋小路に入らないで行き着く先を見てみたいですけどね。
Re: (スコア:0)
わざわざ向いていないことをどうにかしようとするために時間を割くよりは
向いていることをやったほうがいいよ。
実行速度を求めるならRustで書けばいいとおもうのよね。
Re: (スコア:0)
いい内容の書き込みだなぁと思いながら読んでたのに、これで全て壊された。
Re: (スコア:0)
> 当然実行時には型の候補は有限で，実際の型は実行時には一つになります，ただし実行されるたびに型が変わる場合もあります．
型推論が重いのは事実だが、アルゴリズム自体は30年前にselfコンパイラで提案されている。
整数オーバーフロー検出も、実行時プロファイルのAOTコンパイラへのフィードバックと値範囲解析とCPUの投機実行により、オーバーフローしなかったパスの速度低下はかなり～完全に抑えられる。これも20年くらい前からある技術。
Re: (スコア:0)
Re: (スコア:0)
しかしC言語は「整数オーバーフローしたときの動作は未定義です」(=コンパイラーは整数オーバーフローが発生したときのことを一切考えなくていい)というチートを繰り出すからそれでも勝てないんだよな
Re: (スコア:0)
「ほとんどの場合はワード長におさまるが、たまにオーバーフローして多倍長整数で計算しなければならない」ような場合ならPythonが有利になります。Cだとオーバーフローの検出ができないので、ソフトウェア的に判断するか、最初から多倍長で計算するしかない。
Re: (スコア:0)
ソフトウェア的に判断すると言ってもそれはPythonの言語機能がやっていることと同等以上だからそれをもってPythonが有利と言われても意味不明ですね。むしろPythonは必要がなくてもそのチェックを外せない
Re:C／C++と同等もしくはそれ以上の性能 (スコア:1)
たとえばx86にはオーバーフローフラグがあって、整数演算でセットされるから、次の命令で条件分岐するだけです。PyPyもそうしている。意味不明に思えるのはただの無知。
加算がオーバーフローしうるなら
add eax,edx
jo _handle_overflow_and_switch_to_bignum
高頻度パスには条件分岐だけ付け加えればよくて、これは投機実行でコストはほぼ0になる。
ごく単純な仕組みだが、Cは言語レベルではオーバーフローを扱えないので生成不可能なコードになる。
Re: (スコア:0)
>> Cは言語レベルではオーバーフローを扱えないので生成不可能なコードになる。
ずいぶん言語拡張されてるんだからオーバーフローで分岐できるような記述を追加すればいいのにね。
構造化アセンブラなんて言われ方も有るんだし。
Re:C／C++と同等もしくはそれ以上の性能 (スコア:1)
add eax,edx
jo _handle_overflow_and_switch_to_bignum
... ; use eax
高頻度パスがこうだとすると、オーバーフローハンドラは「オーバーフローしうる演算」それぞれと一対一で用意しますが、コードサイズは大きくなく、所詮一回しか実行しません(どれかが一つオーバーフローすると、全体をbignumで処理するコードに切り替えます)。
オーバーフローしたという情報と、それを起こした演算についての知識から、正しい演算結果をbignumで構成することができます。x86なら乗算結果はedx:eaxに入ります(x64も同様)。それからbignum版のルーチンに移行して、戻ってきません。
配列のインデックスなどはvalue range analysisという古くからある技術で、ワードに収まることがわかる場合がほとんどです。たとえばポインタと加減算するための値なら、決してオーバーフローはしません。これは大域的な解析なのでコンパイルは重くなります。
Re: (スコア:0)
当たり前ではないよ。
Objective-CとかC/C++より遅いでしょ。
Re: (スコア:0)
Pythonは変数に型指定がないし多倍長整数を扱っているのでそれが速度にどれくらい影響するか。
CやC++は、32ビットとか64ビット全体を整数を表現するために使い、オーバーフローは気にしない
という実装ができるけど、Pythonではそうはいかないわけで。
Re: (スコア:0)
型指定はあるよ。入れたデータで型が指定される。
動的型付け言語が静的型付け言語かの違い。
まともな知識がないプログラマだと動的型付け言語には型がないと思ってる人がちらほらいる。
Re:C／C++と同等もしくはそれ以上の性能 (スコア:1)
別ACだが、#4426546のACは「変数」に型指定がないと書いている。型指定がないから、
のように書いてもエラーにならない。実行前に「変数」や「引数」の型を決定できないことが多いから、あらゆる型の値を想定する必要があり、最適化をかけにくい。
Re:C／C++と同等もしくはそれ以上の性能 (スコア:1)
こういうのもできるしね。
a=[5,'abc',2**100]
a[0]+1とa[2]+1では違う処理をすることになるんだろうし
a[1]+1はエラー
Lispに勝つ？ (スコア:0)
かなり前に「Lispを手続き型にしたらPythonになる」という記事を読んだことがある。
Lispも速度の遅い言語で、コンパラを通しても思った程の速度は出なかったけど、今度のはどうだろう。
(昔ABC言語なる良さげなプログラム言語を見付けて調べようと思ったら、その開発者が「あれは失敗だった」ってことで新しく作ったのがPythonだったのを知ってガクっと来た)
Re: (スコア:0)
確かめてないけど、
https://valvallow.blogspot.com/2010/06/lisp-c-c.html [blogspot.com]
Common Lispも処理系とプログラミング次第？
「RubyはMatz lispだ」なんてのを見かけた記憶も。
バージョンアップの時に (スコア:0)
名前をOyaCodonと改名して頂きたい
Re: (スコア:0)
名前をOyaCodonと改名して頂きたい
母と娘を何と見做すかそれが問題だ(マテ
Cythonとの違いは？ (スコア:0)
Cを経由せずに直接コンパイルすることだけ？
Python に速度を求めるのか？ (スコア:0)
実行時間のほとんどはC/C++で書かれたモジュールのものじゃないのか
Re: (スコア:0)
Python書き慣れるとそんなに遅くなく書けますよね。
なんというか遅いコーディングを避ける方法がそれなりにある。
Re: (スコア:0)
Python特有のものってあるの？
BASICコンパイラ (スコア:0)
昔からやってる技術だと思うのだけれど
大騒ぎするような技術的課題が有ったのだろうか
Re: (スコア:0)
あの頃のBASICは、変数の型が浮動小数点と文字列しかなくて、名前空間も別れていたような気がするので、Pythonのように変数や引数の型が実行前に分からないということがなかったんじゃないかな。
Re: (スコア:0)
int%、single,double#,str$ だったかなぁ
型はそれぞれありましたね。
面倒なのは文字列が可変長なのでのGCだったような気が
あとは配列長も実行時解決だったかしら
とりあえずDEFINT A-Zで早くなるおまじないw
Re: (スコア:0)
配列はデフォルトで使えるのが10までで、それ以上使いたければDIM宣言が必要じゃなかったっけ？
コンパイラとしてはDIMなしの配列が出てきたら何も考えずに10まで確保するのだと思う。
Re: (スコア:0)
ていうか64KBが大容量メモリだった時代にソースコードとバイナリを別々に保存するなんて贅沢が許されるわけがない。マイコンの言語がインタープリターだったのは必然
codonで (スコア:0)
Python自身をコンパイルできるようになってからが本番
Re: (スコア:0)
OSが書けるようになってようやく一人前
Re: (スコア:0)
OSが書けるようになってようやく一人前
いや待つんだsystemd-pythonになる方が先だろう
CoDen is new answers. (スコア:0)
CoDen is new answers.
という、かつてのNTTコミュニケーションズの思い出した。
Think different.
とどっちが先でしたっけ？
Re: (スコア:0)
NTTコミュニケーションズの「コピーを」思い出した。すみません。