アカウント名:
パスワード:
CLRがVM(JVMのようなインタプリタの発展型)ではないというのも理解不能。中間のバイナリコードをJITでネイティヴコードに変換しながら実行する。どう考えても、JVMの同類じゃないですか。
もちろんそうなんですが、例えばMS CLRはWindows PCの間ですら浮動小数点計算の結果が一致しません。これはJITが実行環境のCPUに依存した最適化命令を出力するためです。実行モードが32-bitモードと64-bitモードでも結果は異なりうるわけです。そんな有様で国際標準規格準拠と言えるのかというと、実はCLIはそういった浮動小数点数演算の実行時最適化を認めているので、CLRはC
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
もともと「実行」は可能 (スコア:0)
昔から VisualStudio でビルドして、mono で実行はできてた。
コンパイラが出たことで、ビルドも mono で出来るようになったって話でしょ?
でも C# のコンパイラもそうだけど、mono 版はコンパイラの最適化がしょぼすぎるんで、結局 MS 純正コンパイラを使うことになるのよね。ビルドだけならどこでやっても同じだし。
VMの実行速度も、とてつもなく差があるけど、MS版の VMは Linux 上で動かす手段がない。
Re:もともと「実行」は可能 (スコア:1)
ところでコンパイルできたとしてもウィンドウプログラムが作れるわけではないので、
あまり意味がないような。わざわざLinuxサーバでASPというのも。。
Re:もともと「実行」は可能 (スコア:0)
いつから .NET ってVM 上で動くものでなくなったんですか?
VM上での実行でなくなるという将来的な話すら、まだ出てきてないようですが、、、
それとも JIT で動く場合もあるので VMの上じゃないとかいう話?
Re:もともと「実行」は可能 (スコア:1)
http://www.users.gr.jp/blogs/hidori/archive/2004/06/25/3316.aspx [users.gr.jp]
おお、前にWineで動かそうとしてると知ったのですが、いまはまた作り直してる。のかしら?
Re:もともと「実行」は可能 (スコア:0)
ITmediaの記事で書いてあるような仮想マシンじゃない
JavaVMといっしょにしないでくれ
という主張であって、一般的な意味でのVirtualMachineであることは
必ずしも否定してないように読めますが。
# つーか、突っ込みうけて言い訳がましくなってるところもあるし
Re:もともと「実行」は可能 (スコア:2, 参考になる)
VM上で動く実行コードはそのVMのバイナリだと思います。
PPC Mac上で動くVirtualPCの実行コードはx86です。
しかし、CLRの場合、プリコンパイルとしてMSILにしますが、
実行時にはMSILからそのマシンのネイティブバイナリにコンパイルされます。
Monoで動く実行バイナリはMZ形式ではなく、ELF形式なはずです。
# でもちょっと不安になってきたり
Re:もともと「実行」は可能 (スコア:0)
これ Javaでも .NET Frameworkで使われてる Just In Time(JIT)コンパイラとどう違いますかね?
他のイメージへの変換を考えずに開発されたマシン語 Virtual Machineというアイデアで開発されたJava JITを前提に開発された .NET
程度の違いはありますが高速化の手法は一致してると思います。
ちなみにLinux での Monoコンパイラが出力するプログラムはMZ形式です。
もちろん binfmtというラッパがMonoを実行するのですが。
というかプログラム形式の
Re:もともと「実行」は可能 (スコア:0)
ところでJITコンパイラでコンパイルされたコードにはVMは必要ないのですが、
その場合もVM上で動いていると表現すべきなのでしょうか?
リンク先の説明を見ても、どこにもVMは出てきませんが。
Re:もともと「実行」は可能 (スコア:1)
>VirtualPCやVM Wareではx86の命令をVM上のCPUではなく実機で直接実行してますね。
以前、「はてな」でもツッコミ入れましたが…。
ここでは気にする必要が無いと思いますが、他で書くときは「Windows版の」という
言葉を入れた方が良いですよ。
VirtualPCは、Windows版よりMacintosh版の歴史が長いので、文章読めずに
「(Macintosh版の)VirtualPCはx86命令を直接実行なんてしてない!」
と言うのがでたりしますんで。
Re:もともと「実行」は可能 (スコア:1)
ある言語で書かれたプログラムを解釈/実行することが目的のVMと、
VMwareやVirtualPCのようなハードウェアを仮想化して、
ほかのOSやCPU用のプログラムを実行することが目的のVMを
同列に語るのは間違いでしょう。
というか、ここでVMwareやVirtualPCが出てくること自体が不思議でしょうがない。
CLRがVM(JVMのようなインタプリタの発展型)ではないというのも理解不能。
中間のバイナリコードをJITでネイティヴコードに変換しながら実行する。
どう考えても、JVMの同類じゃないですか。
Re:もともと「実行」は可能 (スコア:0)
最初 Sunが VM(Write Once, Run Anywhere)で注目を集め Appletとして使われたが巨大なクラスライブラリとメモリ食いで重いと次第に嫌われた。
そこでMicrosoftが重い・メモリ食いというイメージを嫌ったためVMを意図的に避け JITでネイティブコンパイルを売りにした。
こんな感じ?
Re:もともと「実行」は可能 (スコア:1)
>というか、ここでVMwareやVirtualPCが出てくること自体が不思議でしょうがない。
>CLRがVM(JVMのようなインタプリタの発展型)ではないというのも理解不能。
>中間のバイナリコードをJITでネイティヴコードに変換しながら実行する。
>どう考えても、JVMの同類じゃないですか。
”既存のソフトウェア(バイナリ形式)を動かす為に作られた仮装実行環境”と
”汎用を目的として作られたバイナリ形式と仮装実行環境”は
言うまでもなく同列に語るべきではないと思います。
しかし、”仮装実行環境を実ハードウェアで実行できる様に翻訳し、動作させる物”と
いう見方をした場合、”似た扱い”をしてしまうのも致し方ないかと。
JAVAのバイナリを直接実行できるハードウェアがでている現在だと、
CLRとJAVAそれぞれの成り立ちを知らない人は間違いかねないのではないかと。
同僚が”違いのわからない人”なら、小一時間説教というか…教えますが(笑)
#目的は違う物ですが、遠い昔COMET(http://ja.wikipedia.org/wiki/CASL)の
#挙動をTurboCで再現をしようとしていたのを思い出しました。
#私にとって、あれが初めての仮装実行環境でした。なつかしい。
Re:もともと「実行」は可能 (スコア:0)
もちろんそうなんですが、例えばMS CLRはWindows PCの間ですら浮動小数点計算の結果が一致しません。これはJITが実行環境のCPUに依存した最適化命令を出力するためです。実行モードが32-bitモードと64-bitモードでも結果は異なりうるわけです。そんな有様で国際標準規格準拠と言えるのかというと、実はCLIはそういった浮動小数点数演算の実行時最適化を認めているので、CLRはC