パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Monoプロジェクト、GNU/Linux用Visual Basicを発表」記事へのコメント

  • VB.NET は、コンパイルされたら .NET バイナリになるんだから、コンパイラの有無に関係なく実行可能。
    昔から VisualStudio でビルドして、mono で実行はできてた。
    コンパイラが出たことで、ビルドも mono で出来るようになったって話でしょ?

    でも C# のコンパイラもそうだけど、mono 版はコンパイラの最適化がしょぼすぎるんで、結局 MS 純正コンパイラを使うことになるのよね。ビルドだけならどこでやっても同じだし。
    VMの実行速度も、とてつもなく差があるけど、MS版の VMは Linux 上で動かす手段がない。
    • .NETはVMで動くのではありません。

      ところでコンパイルできたとしてもウィンドウプログラムが作れるわけではないので、
      あまり意味がないような。わざわざLinuxサーバでASPというのも。。
      • > .NETはVMで動くのではありません。

        いつから .NET ってVM 上で動くものでなくなったんですか?
        VM上での実行でなくなるという将来的な話すら、まだ出てきてないようですが、、、
        それとも JIT で動く場合もあるので VMの上じゃないとかいう話?
        • CLR は仮想マシンではありません。
          http://www.users.gr.jp/blogs/hidori/archive/2004/06/25/3316.aspx [users.gr.jp]

          おお、前にWineで動かそうとしてると知ったのですが、いまはまた作り直してる。のかしら?
          • リンク先をコメント含めて読む限り、
             ITmediaの記事で書いてあるような仮想マシンじゃない
             JavaVMといっしょにしないでくれ
            という主張であって、一般的な意味でのVirtualMachineであることは
            必ずしも否定してないように読めますが。
            # つーか、突っ込みうけて言い訳がましくなってるところもあるし
            • なにをVMとするか議論の余地があるかもしれませんが、

              VM上で動く実行コードはそのVMのバイナリだと思います。
              PPC Mac上で動くVirtualPCの実行コードはx86です。

              しかし、CLRの場合、プリコンパイルとしてMSILにしますが、
              実行時にはMSILからそのマシンのネイティブバイナリにコンパイルされます。
              Monoで動く実行バイナリはMZ形式ではなく、ELF形式なはずです。

              # でもちょっと不安になってきたり
              • VirtualPCがどの程度高速化してるかはわかりませんが、それなりに歴史のあるソフトなんでループ処理等で局所的にはよく使われる命令郡を最適化してネイティブイメージに変換くらいはやってると思います。
                これ Javaでも .NET Frameworkで使われてる Just In Time(JIT)コンパイラとどう違いますかね?

                他のイメージへの変換を考えずに開発されたマシン語 Virtual Machineというアイデアで開発されたJava JITを前提に開発された .NET
                程度の違いはありますが高速化の手法は一致してると思います。

                ちなみにLinux での Monoコンパイラが出力するプログラムはMZ形式です。
                もちろん binfmtというラッパがMonoを実行するのですが。
                というかプログラム形式の
              • VirtualPCやVM Wareではx86の命令をVM上のCPUではなく実機で直接実行してますね。

                ところでJITコンパイラでコンパイルされたコードにはVMは必要ないのですが、
                その場合もVM上で動いていると表現すべきなのでしょうか?

                リンク先の説明を見ても、どこにもVMは出てきませんが。
              • #コレは余計な話しです。

                >VirtualPCやVM Wareではx86の命令をVM上のCPUではなく実機で直接実行してますね。

                以前、「はてな」でもツッコミ入れましたが…。

                ここでは気にする必要が無いと思いますが、他で書くときは「Windows版の」という
                言葉を入れた方が良いですよ。

                VirtualPCは、Windows版よりMacintosh版の歴史が長いので、文章読めずに
                「(Macintosh版の)VirtualPCはx86命令を直接実行なんてしてない!」
                と言うのがでたりしますんで。
                親コメント
              • JVMやCLRのようなインタプリタの発展型で、
                ある言語で書かれたプログラムを解釈/実行することが目的のVMと、
                VMwareやVirtualPCのようなハードウェアを仮想化して、
                ほかのOSやCPU用のプログラムを実行することが目的のVMを
                同列に語るのは間違いでしょう。
                というか、ここでVMwareやVirtualPCが出てくること自体が不思議でしょうがない。

                CLRがVM(JVMのようなインタプリタの発展型)ではないというのも理解不能。
                中間のバイナリコードをJITでネイティヴコードに変換しながら実行する。
                どう考えても、JVMの同類じゃないですか。
                親コメント
              • VMは SunとMicrosoftのマーケティングが大きかったのかな?

                最初 Sunが VM(Write Once, Run Anywhere)で注目を集め Appletとして使われたが巨大なクラスライブラリとメモリ食いで重いと次第に嫌われた。
                そこでMicrosoftが重い・メモリ食いというイメージを嫌ったためVMを意図的に避け JITでネイティブコンパイルを売りにした。

                こんな感じ?
              • >同列に語るのは間違いでしょう。
                >というか、ここでVMwareやVirtualPCが出てくること自体が不思議でしょうがない。

                >CLRがVM(JVMのようなインタプリタの発展型)ではないというのも理解不能。
                >中間のバイナリコードをJITでネイティヴコードに変換しながら実行する。
                >どう考えても、JVMの同類じゃないですか。

                ”既存のソフトウェア(バイナリ形式)を動かす為に作られた仮装実行環境”と
                ”汎用を目的として作られたバイナリ形式と仮装実行環境”は
                言うまでもなく同列に語るべきではないと思います。

                しかし、”仮装実行環境を実ハードウェアで実行できる様に翻訳し、動作させる物”と
                いう見方をした場合、”似た扱い”をしてしまうのも致し方ないかと。

                JAVAのバイナリを直接実行できるハードウェアがでている現在だと、
                CLRとJAVAそれぞれの成り立ちを知らない人は間違いかねないのではないかと。

                同僚が”違いのわからない人”なら、小一時間説教というか…教えますが(笑)

                #目的は違う物ですが、遠い昔COMET(http://ja.wikipedia.org/wiki/CASL)の
                #挙動をTurboCで再現をしようとしていたのを思い出しました。
                #私にとって、あれが初めての仮装実行環境でした。なつかしい。
                親コメント
              • CLRがVM(JVMのようなインタプリタの発展型)ではないというのも理解不能。
                中間のバイナリコードをJITでネイティヴコードに変換しながら実行する。
                どう考えても、JVMの同類じゃないですか。

                もちろんそうなんですが、例えばMS CLRはWindows PCの間ですら浮動小数点計算の結果が一致しません。これはJITが実行環境のCPUに依存した最適化命令を出力するためです。実行モードが32-bitモードと64-bitモードでも結果は異なりうるわけです。そんな有様で国際標準規格準拠と言えるのかというと、実はCLIはそういった浮動小数点数演算の実行時最適化を認めているので、CLRはC

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

処理中...