アカウント名:
パスワード:
タレコミ: NumbaはPythonのバイトコードで動作しており正しい訳: NumbaはPythonのバイトコードを操作するため
今のPythonはスクリプトを一旦バイトコードに変換してから実行しているのか。知らなかった。だったら「Python自身がJITコンパイラで、NumbaはJITオプティマイザ/アクセラレータ」と説明した方がいいんじゃないかと思った。
> 今のPythonはスクリプトを一旦バイトコードに変換してから実行しているのか。知らなかった。
pythonはかなり昔から スクリプトをバイトコード（仮想マシンコード）に変換して実行していました。# 私が初めて触った 1.5.2 でも中間コードを使っていた。
numba はこのバイトコードを llvm を使ってネイティブコードに JIT コンパイルするモジュールです。
だから、> 「Python自身がJITコンパイラで、NumbaはJITオプティマイザ/アクセラレータ」は明白な間違い。Python は「バイトコードコンパイラ、兼バイトコードインタプリタ」、Numbaが「JITコンパイラ」です。
だとしたら元コメの「NumbaはPythonのバイトコードを操作するため」も間違いってことですね。Numbaはバイトコードを読み込むだけで操作(書き換え)はしないってことだから。
Numba operates on Python bytecode and this is essentially a moving target.
「バイトコードを手術している」だが、意訳して「バイトコードを扱う」あたりが誤解が少ない。実際のところ、バイトコードレベルでトレースを取ったりしてるだろうから、「操作している」も間違いではないだろう。
うーん、バイトコードに対してはトレースなどのリードオンリーなのに「操作してる」はちょっと納得できないです。
それにしてもjavaなどのバイトコードと違って作成するのもそれを解釈して実行するのも同じプログラムで外部から参照されることを考慮する必要はないからバージョンごとに固有の定義でいい、ところがNumbaはそれを取り出してネイティブコードに変換してると。けっこう強引なことをしてるんですね。
バイトコード列であるトレースをNumbaが作成するのだから、「バイトコードを操作する」であっているでしょう。operates on Python bytecodeとあるのだから、一般的な英文の解釈としては、別にPythonがコンパイルしたものには限りません。
あなたが何が何でもPythonの処理系が作ったバイトコードそのものを変更しないと「バイトコードを操作する」とは認めないというのなら知りませんが、そりゃもう言葉が通じませんね。
Pythonが作ったかどうかはどうでもいいです。トレースしてもその結果をバイトコードに反映するわけでないのならソースとして利用しているだけなので「バイトコード"を"操作」とはいえないです。この場合の operates on Python bytecode は「バイトコードによって操作(処理)を行う」でしょう。
> トレースしてもその結果をバイトコードに反映するわけでないのならソースとして利用しているだけなので「バイトコード"を"操作」とはいえないです。
Tracing JITは実行されるバイトコードを順に並べてトレース(バイトコード列)を生成します。分岐頻度などの情報に基づいてトレースを変更します。トレースの実行回数が閾値を越えるとネイティブコードにコンパイルします。そうでないJITでも、分岐頻度などの情報に基づき基本ブロック(バイトコード列)をつないで大きなブロックにしていきます。大きなブロックのほうが最適化の余地が生まれるからです。どちらの場合でも、欲しいものは高頻度な実行パスであり、それ以上の解析はしないので、通常はバイトコードを並べたものを生成・変更します。こんなところで他の表現に変換してもオーバーヘッドになるだけだからです。コンパイルする際にはじめてSSAなどに変換してから最適化とネイティブコード生成を行います。
単にあなたが無知なだけです。
高速化が目的のJITコンパイラがやることは
1. 高頻度な実行パスの特定2. パスの最大化3. パスの実行回数が閾値を越えたらコンパイル
です。あまり実行しないパスをコンパイルしても無駄だし、コンパイルの対象となるパスが長いほど最適化のチャンスがあるからです。1,2で利用するのは実行プロファイルだけなので、通常は元のバイトコード(のブロック)を適宜並べ替えたものを配列に格納してパスの表現とします。実行プロファイルに基づいて、可能な限りパスを大きくします。バイトコードインタプリタに戻る地点にちょっと細工をします。3でコンパイルする際にはじめてパスのバイトコード列をSSAなどの使いやすい表現(NumbaならLLVMでしょう)に変更し、SSAに対して解析や最適化などを施し、最終的にネイティブコードに落とします。変換するだけでもレジスタ割り当てとかあってそれなりに重いです。
albireoさん、いい年したおっさんが知ったかは見苦しいですよ。
どんなJITコンパイラであれ、元のバイトコードの一部を「JITコンパイルしたネイティブコードの呼び出し」で置き換える必要があります。バイトコードのフェッチの度にテーブルを引くとオーバーヘッドが大きすぎるからです。これは操作とは言いませんかそうですか。
＞いい年したおっさんが知ったかは見苦しい知ったかぶりをしている箇所は無いから、単に知らんで言ってるだけだろう知っている人間にとって見苦しいのはさもありなん、しかし俺にはアンタみたいに何でも知ったか知ったかと付ける輩の方が見苦しい
見苦しいのは、調べもせずに事実ではないことをしつこく書くことです。読者が間違った知識を得てしまう可能性があるのがその理由です。心情的なものではありません。それは価値観の問題でしかない。
これが知ったかぶりでなければ何が知ったかぶりだというのか。あれげの基準は少なくとも知ったかぶりに関してはゆるゆるで困る。などと知ったかぶりを…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
タレコミ訳がおかしいから、わけが分からないのか... (スコア: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)
これが知ったかぶりでなければ何が知ったかぶりだというのか。
あれげの基準は少なくとも知ったかぶりに関してはゆるゆるで困る。
などと知ったかぶりを…