アカウント名:
パスワード:
書き直すと、どんな御利益が有るの?
そこには.net上で元気に走り回るJavaVMが!
.netもスタックマシンだがコレも止めるべきっすか?
// っていうかCPU非依存のバイトコードとしてはスタックマシンってかなり優秀な部類では?// どうせ指摘するならインタプリト前提のバイトコードはいい加減止めても良いくらいにしとくべきだと思う
横からですが。今は貴方のおっしゃる通り、JIT全盛で、javaコマンドは標準でJIT&HotSpotを使うでしょ。-Xintを指定して、動的コンパイルせずにインタープリタだけで走らすことは、ほとんどない。なら、いっそインタープリタもバイトコードも切り捨てて、ソースコードから動的コンパイルしちゃえばいいんじゃない?という話かと。インタープリタ前提のバイトコードは、ソースコードそのものを扱うのと大して変わらないしね。バイトコードから逆コンパイルしちゃえばほぼそのままのソースコードが出てくるし。
WORAは保てるし、一度実行すればJITコンパイラ
インタプリタで速度を稼ぐ手段が中間言語にコンパイルすることなんだが、分かっているんだろうか。実行時の字句解析や構文解析のコストは安くないよ。だから、環境異存ではないコードを配布するのにソースコードではなく、バイトコードを利用するのは理にかなっている。
実行時に関して言えば、ネイティブコードへのコンパイルはコスト次第なんじゃないかな。コンパイルの時間も然ることながら、メモリの消費もそれなりにある。今のPCの様に潤沢なメモリがある環境だったり、長時間プログラムを動かしたりするなら、インタプリタのメリットは少ないけど、必ずしもそうではない。
そんなことを言っている間に、どんどん計算機の性能は上がっていますよ。組み込みも含めて。バイトコードを生成するコストの比重は、下がり続けている。…これって、将来の展望のお話をしているんですよね?
そういえば、最近は-serverオプションが標準になりましたね。計算機の性能が全般的に上がったから。
君がPCしか見えていないのはよくわかった
将来性という点においても、少なくとも、字句・構文解析のフェーズと実行フェーズを分けておいた方が、拡張性の面で有利なんだから、コンパイラと仮想マシンを分けることは悪い選択ではない。そうしておけば、コンパイラを新たに書くだけで、別の言語で書かれたプログラムを処理することも可能になるし、逆に仮想マシンだけを置き換えることが容易なことは言うまでもない。
ハードウェアの性能向上するからと言って、開発の面でも処理速度の面でも効率的なものを捨てる理由にはならないよ。
> コンパイラを新たに書くだけで、別の言語で書かれたプログラムを処理することも可能になるし、そんな「ぼくのかんがえたさいきょうのさいりようかのうもじゅーる」だけど実際には一度も再利用されたことがない、の典型みたいな例を出されてもなあ。そもそもコンパイラだけ書きなおしたところでここんとこ連発してるVMの脆弱性には無力じゃん。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
で? (スコア:2)
書き直すと、どんな御利益が有るの?
Re: (スコア:1)
そこには.net上で元気に走り回るJavaVMが!
Re: (スコア:0)
Re: (スコア:0)
.netもスタックマシンだがコレも止めるべきっすか?
// っていうかCPU非依存のバイトコードとしてはスタックマシンってかなり優秀な部類では?
// どうせ指摘するならインタプリト前提のバイトコードはいい加減止めても良いくらいにしとくべきだと思う
Re: (スコア:2)
僕はむしろ、バイトコード+JITに未来というか、現在進行形での良い世界を描いていたので、この意見には?なんですが、
具体的にはどういう話でしょうか?
Re: (スコア:0)
横からですが。
今は貴方のおっしゃる通り、JIT全盛で、javaコマンドは標準でJIT&HotSpotを使うでしょ。-Xintを指定して、動的コンパイルせずにインタープリタだけで走らすことは、ほとんどない。なら、いっそインタープリタもバイトコードも切り捨てて、ソースコードから動的コンパイルしちゃえばいいんじゃない?という話かと。インタープリタ前提のバイトコードは、ソースコードそのものを扱うのと大して変わらないしね。バイトコードから逆コンパイルしちゃえばほぼそのままのソースコードが出てくるし。
WORAは保てるし、一度実行すればJITコンパイラ
Re: (スコア:0)
インタプリタで速度を稼ぐ手段が中間言語にコンパイルすることなんだが、分かっているんだろうか。実行時の字句解析や構文解析のコストは安くないよ。だから、環境異存ではないコードを配布するのにソースコードではなく、バイトコードを利用するのは理にかなっている。
実行時に関して言えば、ネイティブコードへのコンパイルはコスト次第なんじゃないかな。コンパイルの時間も然ることながら、メモリの消費もそれなりにある。今のPCの様に潤沢なメモリがある環境だったり、長時間プログラムを動かしたりするなら、インタプリタのメリットは少ないけど、必ずしもそうではない。
Re:で? (スコア:0)
そんなことを言っている間に、どんどん計算機の性能は上がっていますよ。組み込みも含めて。
バイトコードを生成するコストの比重は、下がり続けている。
…これって、将来の展望のお話をしているんですよね?
そういえば、最近は-serverオプションが標準になりましたね。計算機の性能が全般的に上がったから。
Re: (スコア:0)
君がPCしか見えていないのはよくわかった
Re: (スコア:0)
将来性という点においても、少なくとも、字句・構文解析のフェーズと実行フェーズを分けておいた方が、拡張性の面で有利なんだから、コンパイラと仮想マシンを分けることは悪い選択ではない。そうしておけば、コンパイラを新たに書くだけで、別の言語で書かれたプログラムを処理することも可能になるし、逆に仮想マシンだけを置き換えることが容易なことは言うまでもない。
ハードウェアの性能向上するからと言って、開発の面でも処理速度の面でも効率的なものを捨てる理由にはならないよ。
Re: (スコア:0)
> コンパイラを新たに書くだけで、別の言語で書かれたプログラムを処理することも可能になるし、
そんな「ぼくのかんがえたさいきょうのさいりようかのうもじゅーる」だけど実際には一度も再利用されたことがない、の典型みたいな例を出されてもなあ。
そもそもコンパイラだけ書きなおしたところでここんとこ連発してるVMの脆弱性には無力じゃん。