アカウント名:
パスワード:
書き直すと、どんな御利益が有るの？
そこには.net上で元気に走り回るJavaVMが！
.netもスタックマシンだがコレも止めるべきっすか？
// っていうかCPU非依存のバイトコードとしてはスタックマシンってかなり優秀な部類では？// どうせ指摘するならインタプリト前提のバイトコードはいい加減止めても良いくらいにしとくべきだと思う
横からですが。今は貴方のおっしゃる通り、JIT全盛で、javaコマンドは標準でJIT&HotSpotを使うでしょ。-Xintを指定して、動的コンパイルせずにインタープリタだけで走らすことは、ほとんどない。なら、いっそインタープリタもバイトコードも切り捨てて、ソースコードから動的コンパイルしちゃえばいいんじゃない？という話かと。インタープリタ前提のバイトコードは、ソースコードそのものを扱うのと大して変わらないしね。バイトコードから逆コンパイルしちゃえばほぼそのままのソースコードが出てくるし。
WORAは保てるし、一度実行すればJITコンパイラがコンパイルしたネイティブコードをストアしておけば、実行速度のペナルティも少ない。ソースコードとバイトコードが一対一の関係にあるのであれば、バイトコードを用いるメリットって何？バイトコードはソースコードそのもので代替できるんじゃないの？代替できるなら、必須ではないよね。客にソースコードを見せたくないっていうニーズはあるだろうけど、前述の通り今のバイトコードはソースコードをそのまま公開しているのと大して変わらないし。
# それなんてPython。や、私はJavaプログラマであって、Pythonはほとんど使っていないのですが。
# HotSpot側のバグだったんですが、HotSpotとインタープリタの挙動の違いに悩まされたことがあります。# Javaの場合、インタープリタの方が若干信用できるというのもあるので、インタープリタと動的コンパイラとで実装が複数あるのも# 無駄じゃないかも知れませんが…。
CPythonのpycバイトコードのことをおっしゃっているのでしたら、あれはネイティブコードではありませんよ。ホスト環境非依存の、Python Virtual Machineという仮想マシンの上で動くバイトコードです。CPythonには標準で逆アセンブラモジュール dis がついているので、どんなニーモニックにコンパイルされているのかを見ることも簡単です。例えば、
def f(x): return x**2
という関数を逆アセンブルしてみると、
2 0 LOAD_FAST 0 (x) 3 LOAD_CONST 1 (2) 6 BINARY_POWER 7 RETURN_VALUE
となります。Javaで言うと、javacとjavaが一体化されているようなものですね。
ソースコードとバイトコードは1対1ではないですね。そこにバイトコードのメリットがあるかと思います。バイトコードでは実装されているがソースでは分かりにくい機能とかを予約語として定義しなおしたり。
#バイナリからアセンブリ言語へ戻すことはできるけど、だからといって高級言語いらないよねという#話にならないのと一緒かと。
インタプリタで速度を稼ぐ手段が中間言語にコンパイルすることなんだが、分かっているんだろうか。実行時の字句解析や構文解析のコストは安くないよ。だから、環境異存ではないコードを配布するのにソースコードではなく、バイトコードを利用するのは理にかなっている。
実行時に関して言えば、ネイティブコードへのコンパイルはコスト次第なんじゃないかな。コンパイルの時間も然ることながら、メモリの消費もそれなりにある。今のPCの様に潤沢なメモリがある環境だったり、長時間プログラムを動かしたりするなら、インタプリタのメリットは少ないけど、必ずしもそうではない。
そんなことを言っている間に、どんどん計算機の性能は上がっていますよ。組み込みも含めて。バイトコードを生成するコストの比重は、下がり続けている。…これって、将来の展望のお話をしているんですよね？
そういえば、最近は-serverオプションが標準になりましたね。計算機の性能が全般的に上がったから。
君がPCしか見えていないのはよくわかった
将来性という点においても、少なくとも、字句・構文解析のフェーズと実行フェーズを分けておいた方が、拡張性の面で有利なんだから、コンパイラと仮想マシンを分けることは悪い選択ではない。そうしておけば、コンパイラを新たに書くだけで、別の言語で書かれたプログラムを処理することも可能になるし、逆に仮想マシンだけを置き換えることが容易なことは言うまでもない。
ハードウェアの性能向上するからと言って、開発の面でも処理速度の面でも効率的なものを捨てる理由にはならないよ。
> コンパイラを新たに書くだけで、別の言語で書かれたプログラムを処理することも可能になるし、そんな「ぼくのかんがえたさいきょうのさいりようかのうもじゅーる」だけど実際には一度も再利用されたことがない、の典型みたいな例を出されてもなあ。そもそもコンパイラだけ書きなおしたところでここんとこ連発してるVMの脆弱性には無力じゃん。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
で？ (スコア:2)
書き直すと、どんな御利益が有るの？
Re: (スコア:1)
そこには.net上で元気に走り回るJavaVMが！
Re: (スコア:0)
Re: (スコア:0)
.netもスタックマシンだがコレも止めるべきっすか？
// っていうかCPU非依存のバイトコードとしてはスタックマシンってかなり優秀な部類では？
// どうせ指摘するならインタプリト前提のバイトコードはいい加減止めても良いくらいにしとくべきだと思う
Re: (スコア:2)
僕はむしろ、バイトコード+JITに未来というか、現在進行形での良い世界を描いていたので、この意見には？なんですが、
具体的にはどういう話でしょうか？
Re:で？ (スコア:0)
横からですが。
今は貴方のおっしゃる通り、JIT全盛で、javaコマンドは標準でJIT&HotSpotを使うでしょ。-Xintを指定して、動的コンパイルせずにインタープリタだけで走らすことは、ほとんどない。なら、いっそインタープリタもバイトコードも切り捨てて、ソースコードから動的コンパイルしちゃえばいいんじゃない？という話かと。インタープリタ前提のバイトコードは、ソースコードそのものを扱うのと大して変わらないしね。バイトコードから逆コンパイルしちゃえばほぼそのままのソースコードが出てくるし。
WORAは保てるし、一度実行すればJITコンパイラがコンパイルしたネイティブコードをストアしておけば、実行速度のペナルティも少ない。ソースコードとバイトコードが一対一の関係にあるのであれば、バイトコードを用いるメリットって何？バイトコードはソースコードそのもので代替できるんじゃないの？代替できるなら、必須ではないよね。客にソースコードを見せたくないっていうニーズはあるだろうけど、前述の通り今のバイトコードはソースコードをそのまま公開しているのと大して変わらないし。
# それなんてPython。や、私はJavaプログラマであって、Pythonはほとんど使っていないのですが。
# HotSpot側のバグだったんですが、HotSpotとインタープリタの挙動の違いに悩まされたことがあります。
# Javaの場合、インタープリタの方が若干信用できるというのもあるので、インタープリタと動的コンパイラとで実装が複数あるのも
# 無駄じゃないかも知れませんが…。
Re:で？ (スコア:2)
CPythonのpycバイトコードのことをおっしゃっているのでしたら、あれはネイティブコードではありませんよ。
ホスト環境非依存の、Python Virtual Machineという仮想マシンの上で動くバイトコードです。
CPythonには標準で逆アセンブラモジュール dis がついているので、どんなニーモニックにコンパイルされているのかを見ることも簡単です。例えば、
という関数を逆アセンブルしてみると、
となります。
Javaで言うと、javacとjavaが一体化されているようなものですね。
Re: (スコア:0)
ソースコードとバイトコードは1対1ではないですね。そこにバイトコードのメリットがあるかと思います。
バイトコードでは実装されているがソースでは分かりにくい機能とかを予約語として定義しなおしたり。
#バイナリからアセンブリ言語へ戻すことはできるけど、だからといって高級言語いらないよねという
#話にならないのと一緒かと。
Re: (スコア:0)
インタプリタで速度を稼ぐ手段が中間言語にコンパイルすることなんだが、分かっているんだろうか。実行時の字句解析や構文解析のコストは安くないよ。だから、環境異存ではないコードを配布するのにソースコードではなく、バイトコードを利用するのは理にかなっている。
実行時に関して言えば、ネイティブコードへのコンパイルはコスト次第なんじゃないかな。コンパイルの時間も然ることながら、メモリの消費もそれなりにある。今のPCの様に潤沢なメモリがある環境だったり、長時間プログラムを動かしたりするなら、インタプリタのメリットは少ないけど、必ずしもそうではない。
Re: (スコア:0)
そんなことを言っている間に、どんどん計算機の性能は上がっていますよ。組み込みも含めて。
バイトコードを生成するコストの比重は、下がり続けている。
…これって、将来の展望のお話をしているんですよね？
そういえば、最近は-serverオプションが標準になりましたね。計算機の性能が全般的に上がったから。
Re: (スコア:0)
君がPCしか見えていないのはよくわかった
Re: (スコア:0)
将来性という点においても、少なくとも、字句・構文解析のフェーズと実行フェーズを分けておいた方が、拡張性の面で有利なんだから、コンパイラと仮想マシンを分けることは悪い選択ではない。そうしておけば、コンパイラを新たに書くだけで、別の言語で書かれたプログラムを処理することも可能になるし、逆に仮想マシンだけを置き換えることが容易なことは言うまでもない。
ハードウェアの性能向上するからと言って、開発の面でも処理速度の面でも効率的なものを捨てる理由にはならないよ。
Re: (スコア:0)
> コンパイラを新たに書くだけで、別の言語で書かれたプログラムを処理することも可能になるし、
そんな「ぼくのかんがえたさいきょうのさいりようかのうもじゅーる」だけど実際には一度も再利用されたことがない、の典型みたいな例を出されてもなあ。
そもそもコンパイラだけ書きなおしたところでここんとこ連発してるVMの脆弱性には無力じゃん。