Python向けのJITコンパイラ「Numba」に関して、そのGithub上でその開発における内情が紹介されている。Python 3.11をサポートしたいわゆる新バージョンの「進捗どうですか？」の質問に回答する形でおこなわれている。曰く、NumbaはPythonのバイトコードで動作しており、Pythonのマイナーリリースごとに、Numbaを新しいバイトコードのバージョンに追従させる必要があり、その作業には3～6か月の期間、作業が必要であるとしている（GitHub）。
タレコミ訳がおかしいから、わけが分からないのか... (スコア:3, 参考になる)
タレコミ: NumbaはPythonのバイトコードで動作しており
正しい訳: NumbaはPythonのバイトコードを操作するため
Re:タレコミ訳がおかしいから、わけが分からないのか... (スコア:1)
今のPythonはスクリプトを一旦バイトコードに変換してから実行しているのか。知らなかった。
だったら「Python自身がJITコンパイラで、NumbaはJITオプティマイザ/アクセラレータ」と説明した方がいいんじゃないかと思った。
うじゃうじゃ
Re: (スコア:0)
> 今のPythonはスクリプトを一旦バイトコードに変換してから実行しているのか。知らなかった。
pythonはかなり昔から スクリプトをバイトコード（仮想マシンコード）に変換して実行していました。
# 私が初めて触った 1.5.2 でも中間コードを使っていた。
numba はこのバイトコードを llvm を使ってネイティブコードに JIT コンパイルするモジュールです。
だから、
> 「Python自身がJITコンパイラで、NumbaはJITオプティマイザ/アクセラレータ」
は明白な間違い。
Python は「バイトコードコンパイラ、兼バイトコードインタプリタ」、Numbaが「JITコンパイラ」です。
Re:タレコミ訳がおかしいから、わけが分からないのか... (スコア:1)
だとしたら元コメの「NumbaはPythonのバイトコードを操作するため」も間違いってことですね。
Numbaはバイトコードを読み込むだけで操作(書き換え)はしないってことだから。
うじゃうじゃ
Re: (スコア:0)
Numba operates on Python bytecode and this is essentially a moving target.
「バイトコードを手術している」だが、意訳して「バイトコードを扱う」あたりが誤解が少ない。
実際のところ、バイトコードレベルでトレースを取ったりしてるだろうから、「操作している」も間違いではないだろう。
Re:タレコミ訳がおかしいから、わけが分からないのか... (スコア:1)
うーん、バイトコードに対してはトレースなどのリードオンリーなのに「操作してる」はちょっと納得できないです。
それにしてもjavaなどのバイトコードと違って作成するのもそれを解釈して実行するのも同じプログラムで外部から参照されることを考慮する必要はないからバージョンごとに固有の定義でいい、ところがNumbaはそれを取り出してネイティブコードに変換してると。
けっこう強引なことをしてるんですね。
うじゃうじゃ
Re: (スコア:0)
バイトコード列であるトレースをNumbaが作成するのだから、「バイトコードを操作する」であっているでしょう。operates on Python bytecodeとあるのだから、一般的な英文の解釈としては、別にPythonがコンパイルしたものには限りません。
あなたが何が何でもPythonの処理系が作ったバイトコードそのものを変更しないと「バイトコードを操作する」とは認めないというのなら知りませんが、そりゃもう言葉が通じませんね。
Re:タレコミ訳がおかしいから、わけが分からないのか... (スコア:1)
Pythonが作ったかどうかはどうでもいいです。
トレースしてもその結果をバイトコードに反映するわけでないのならソースとして利用しているだけなので「バイトコード"を"操作」とはいえないです。
この場合の operates on Python bytecode は「バイトコードによって操作(処理)を行う」でしょう。
うじゃうじゃ
Re: (スコア:0)
> トレースしてもその結果をバイトコードに反映するわけでないのならソースとして利用しているだけなので「バイトコード"を"操作」とはいえないです。
Tracing JITは実行されるバイトコードを順に並べてトレース(バイトコード列)を生成します。分岐頻度などの情報に基づいてトレースを変更します。トレースの実行回数が閾値を越えるとネイティブコードにコンパイルします。
そうでないJITでも、分岐頻度などの情報に基づき基本ブロック(バイトコード列)をつないで大きなブロックにしていきます。大きなブロックのほうが最適化の余地が生まれるからです。
どちらの場合でも、欲しいものは高頻度な実行パスであり、それ以上の解析はしないので、通常はバイトコードを並べたものを生成・変更します。こんなところで他の表現に変換してもオーバーヘッドになるだけだからです。コンパイルする際にはじめてSSAなどに変換してから最適化とネイティブコード生成を行います。
単にあなたが無知なだけです。
Re: (スコア:0)
高速化が目的のJITコンパイラがやることは
1. 高頻度な実行パスの特定
2. パスの最大化
3. パスの実行回数が閾値を越えたらコンパイル
です。あまり実行しないパスをコンパイルしても無駄だし、コンパイルの対象となるパスが長いほど最適化のチャンスがあるからです。
1,2で利用するのは実行プロファイルだけなので、通常は元のバイトコード(のブロック)を適宜並べ替えたものを配列に格納してパスの表現とします。実行プロファイルに基づいて、可能な限りパスを大きくします。バイトコードインタプリタに戻る地点にちょっと細工をします。
3でコンパイルする際にはじめてパスのバイトコード列をSSAなどの使いやすい表現(NumbaならLLVMでしょう)に変更し、SSAに対して解析や最適化などを施し、最終的にネイティブコードに落とします。変換するだけでもレジスタ割り当てとかあってそれなりに重いです。
albireoさん、いい年したおっさんが知ったかは見苦しいですよ。
Re: (スコア:0)
どんなJITコンパイラであれ、元のバイトコードの一部を「JITコンパイルしたネイティブコードの呼び出し」で置き換える必要があります。バイトコードのフェッチの度にテーブルを引くとオーバーヘッドが大きすぎるからです。これは操作とは言いませんかそうですか。
Re: (スコア:0)
＞いい年したおっさんが知ったかは見苦しい
知ったかぶりをしている箇所は無いから、単に知らんで言ってるだけだろう
知っている人間にとって見苦しいのはさもありなん、しかし俺にはアンタみたいに何でも知ったか知ったかと付ける輩の方が見苦しい
Re: (スコア:0)
見苦しいのは、調べもせずに事実ではないことをしつこく書くことです。読者が間違った知識を得てしまう可能性があるのがその理由です。心情的なものではありません。それは価値観の問題でしかない。
Re: (スコア:0)
これが知ったかぶりでなければ何が知ったかぶりだというのか。
あれげの基準は少なくとも知ったかぶりに関してはゆるゆるで困る。
などと知ったかぶりを…
Re: (スコア:0)
ちなみに、この文が言いたいことは「NumbaはPythonのソースコードではなく、バイトコードを扱っている」
ソースコードは同じでも処理系のバージョンが違うとバイトコードが違うので大変だということ。
Re: (スコア:0)
そうですね。元コメは間違い。そも理解していない。
>バイトコードの数と各バイトコードの動作は、Python のマイナー バージョンごとに大きく異なります
元記事をgoogleで訳すとこうなったけど、要はバイトコードの数値とそれに対する動作が決まってなくて
バージョンごとにコロコロ変わるから追従が大変。ということだね。
それは無理というものだよそんなの・・・w
いちいち解析から始まるのかバージョン変わったら?
Python処理系のソースから相当するテーブルとか自動生成するとか考えられないのかな
しんどいなそれ (スコア:0)
Pythonのマイナーリリースごとに何か月もかけて対応って
そのうち疲れてやめちゃいそうで心配。
Re:しんどいなそれ (スコア:1)
しかも無償でやってるとなるとさらに
最初は興味があってやるのでいいんだろうけど
バージョンアップ毎に作業が多いのはつらい
ちなみにPHPのJITのソースを一度見た時は面倒なマクロが大量に書いてあった
同じではないと思うけど、メンテナンスが凄く面倒なのは一緒かも？
少人数でメンテするのが大変だと言ってたな
Re:しんどいなそれ (スコア:1)
あんまり遅れるとJAXやCuPyにユーザーが流れそう
Re: (スコア:0)
うん。なぜソースがないのか？オレなのか？
Re: (スコア:0)
後半がちょっと意外。なんでそんなことになってるんだ？
Re: (スコア:0)
LLVMのビットコードやV8のバイトコードにしても自プロジェクトだけが使うなら、外部向けインターフェースとして定義しないほうが設計やバージョンアップの自由度上がるから、Javaや.NETのように開発元の違う複数言語で使いたいってんじゃなければ普通の選択だろう。
Re:しんどいなそれ (スコア:2, 参考になる)
Sunの時代から Javaのバイトコードの振舞は、マイナーバージョンで変わったりするけどな。
当時、バグレポート投げたら同じバージョン間での互換性はプラットホーム違っても頑張る(ベンダに頑張ってもらう)けど、バージョン間で互換なくなるのは、そういう方針ですって公式に回答もらったよ。
まぁ、あの時のJavaVMは Java以外の言語から使うことはあんまり想定してなかったかもしれんけど。
Re: (スコア:0)
つってもアプリの実行者に提供するのは通常はjarに入ったクラスファイルでバイトコードだから、
実行したいアプリごとにJREのバージョン決め打てと………
ああ、公式がそういう見解だから
Javaアプリの提供者がクソ古いJREの導入とバージョンアップ停止を要求するなんてクソ文化が爆誕したのか。
検証コスト回避名目のクソ対応でもあるんだろうけど、そもそもはSunが原因作ってたんだ……
脆弱性対応が一般化していった時期に、Sunも例にもれずアップデートしろしろ言ってたとは思うけど、
アップデートしたら動かしたいアプリが死ぬかもしれんけどやれって無茶振りになってしまうと……
デスクトップアプリやブラウザアプレット用途ではJavaは嫌われるべくして嫌われたんだな。
Re: (スコア:0)
面倒だからSqueak使って開発すればいいじゃん
「進捗どうですか？」 (スコア:0)
その言葉を聞くたびに胃がキリキリ・・・・
# 「無ぇもんは無ぇんだよ！」
Re: (スコア:0)
80%以降の歩みの遅さといったらね...
二～歩進んで三歩下がる～
Re: (スコア:0)
とは言え、そうやって定期的に聞かれないとやる気でないでしょう？
# もう、今日は帰れない
タイトルだけを見て (スコア:0)
なぜ梅田ダンジョンやうめきた開発1期・2期のように順調に発展せず、
衰退しつつある南海／大阪メトロなんば駅周辺とか閑散としているでんでんタウンの話かと思った
JITコンパイラである必要あるのか (スコア:0)
この分野は素人の意見ですけど
普通にネイティブコンパイラはできないもんですかね
(あるいはC/C++へのトランスレータでも)
JITのほうがむつかしいのではと思うのですが
Re: (スコア:0)
トランスレータ、Cythonというのがあるみたいですね。
Cとかも解るならこっちのほうがいいかな。
pythonしか知らない人が手軽に高速化できる、ってのが
JITのメリットなんでしょうけどね
Re: (スコア:0)
ぶっちゃけJITのほうがずっと簡単です。事前コンパイルだと面倒なプログラムの大域的な解析をしないと性能がでませんが、JITだと実行時の統計を取れば簡単にできるからです。一長一短ではあるので、事前コンパイルのほうが向いている言語もあります。
Re: (スコア:0)
Nuitkaとかあるよ。まあそもそもパイインストーラみたいなパッケージングツールですらパイソンのバージョン・アップのたびに動かなくなるけども。