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

VT を搭載した「Pentium 4 672/662」発表へ」記事へのコメント

  • 普段 Windows で Linux 用のソフトを作るときには coLinux 使ってて、それ以外の用途でも今使ってる VMware Player でなんら不満のない自分は、具体的に VT で新しく何ができるようになるのか見当もつきません。単に早くなるだけ?だったらプロセッサのパフォーマンスを全体的に引き上げるのと同じだよなぁ。

    VMM のための新しい命令が追加されるの?それってたとえば SIMD 命令群が用意されたから特定の処理が早くなりますよ、うれしいね、ってのと似てる?わかんないんでとりあえず Intel の文書 [intel.com]に当たってみます。
    --
    屍体メモ [windy.cx]
    • VT なんて書かれると何のことか判らないけど、VMware のような仮想化システムをサポートするアーキテクチャ (命令群) を CPUが内蔵するわけですな。

      従来 VMware 上などで実行するOS/プログラムの性能が、直接インストールしたものに比べてかなり性能低下するのが、これによってほとんど直接実行しているのと変わらなくなるでしょう。

      こういった命令が一般化すれば、恩恵を受けるのは複数OSを使う必要がある開発者ばかりでなく、仮想化OSをサンドボックスとしてウィルス保護に使うなど、応用も広がると思います。

      まあ、これらはメインフレームが辿った道なんで、順当な路線ということでしょう。

      --
      • >> こういった命令が一般化すれば、恩恵を受けるのは複数OSを使う必要がある開発者ばかりでなく、仮想化OSをサンドボックスとしてウィルス保護に使うなど、応用も広がると思います。

        ド素人なんで的外れかもしれませんが、もしかしてJavaのVMも幸せになったりするんでしょうか?
        • コメントがついてないようなので今週は暇人の私めが一言。(別に専門家ってわけでは全然ないので識者の方のつっこみ大歓迎です。)

          Java VMの命令セットと物理CPUの命令セットの間に特に関係がある訳じゃないんで、残念ながら幸せになったりはしないと思います。

          今回の話っていうのはいわば物理CPUの命令を直接使うOSたちをだましてしまおうという話なので、物理CPUをそのまま使う訳ではないJava VMには直接の関係はないといえるでしょう。

          # 投稿ついでに余計なものもくっつけておきますね。

          ずいぶん前からVMwareを使ってますけど、I/Oの絡まない処理は
          • Java VMの命令セットと物理CPUの命令セットの間に特に関係がある訳じゃないんで、残念ながら幸せになったりはしないと思います。
            そうでもないですよ。
            JRockit VM の BEA Systems は Bare Metal [beasys.co.jp] なんてものを考えています。
            また、今後のユーティリティコンピューティングの実現を目指した取り組みの1つとして、ハードウェアおよびアプリケーションの仮想化テクノロジーを活用することで、OSを介在することなくIntelのVT(Virtualization Technology)対応プロセッサ上で直接JRockitを実行可能にするプロジェクト「Bare Metal」も紹介された。
            ZDNet: 10年間でサービスインフラベンダーに変革したBEAシステムズ [zdnet.com]
            はっきりとした詳細は不明ですが、ゲストOSを丸ごと一つの Java VM にするんだと推測しています。
            --
            コンタミは発見の母
            親コメント
            • 早速のご指摘ありがとうございます。世の中知らないことはたくさんあるもんですね。こうして教えていただいたということで駄文を省みず投稿してみた甲斐がありました。

              言われてみれば直接高速化を図らずともこういった手段はありますね。

              ちょっと探してみたら上記Bare Metalに関しては日経IT Proの方にも記事 [nikkeibp.co.jp]がありました。

              確かに実現すればJava VMの下に汎用OSが寝ている分のオーバーヘッドは回避できそうです。ハードウェアJava Machineを作ったりする方が劇的な効果が望めるでしょうけれど、イニシャルコストや陳腐化その他のリスクを考えると実現可能性という点ではこちらの方が数段高そうです。

              最後にもう一度情報どうもありがとうございました。Java VMのパフォーマンス向上で幸せになれる人はこのプロジェクトが立ち消えにならないことを祈りましょう(^^;
              親コメント
              • by fault (18699) on 2005年11月15日 20時13分 (#832296)
                > Java VMの下に汎用OSが寝ている分のオーバーヘッドは回避できそうです

                既に、ITRONなどのRealTimeOS上のJavaVMなどはごろごろしています。オーバヘッドの少なさだけならこっちの方が有利そうです。ただし、これらの実装で性能が稼げそうなのは、大量のスレッドを動かすような使い方をしたときだけだと思います。

                それでも汎用のOSと一緒に、この高性能JavaVMを同時に動かせるのは悪くはないですね。

                親コメント
              • by magicalchalk (27784) on 2005年11月16日 13時42分 (#832836)
                既に、ITRONなどのRealTimeOS上のJavaVMなどはごろごろしています。オーバヘッドの少なさだけならこっちの方が有利そうです。ただし、これらの実装で性能が稼げそうなのは、大量のスレッドを動かすような使い方をしたときだけだと思います。

                いや、RealTime OS の上に載っているのが Java VM だけで他のネイティブコードが走っていないなら、CPU をスーパーバイザモードで突っ走らせるという荒業があります。

                アプリケーションが全部 Pure Java コードなら、プロセス外のメモリへの参照も特権命令の勝手な実行も起きません。それらは全て Java VM が監視できます。すると CPU のユーザモードを使う必要がなくてスーパバイザモードのまま走らせても安全なんです。

                これは I/O の速度に効いてきます。I/O 処理中に CPU のモードを切り替える必要がありませんから。なのでそんな環境はネットワーク通信だけ妙に早かったりします。

                実用場面では Pure Java では実用性に欠けるので広まりませんでしたが、ネタとしては面白いと今でも思っています。

                親コメント
              • 前の記事の参照先を見ればよかったです。

                実用場面では Pure Java では実用性に欠けるので広まりませんでしたが、ネタとしては面白いと今でも思っています。

                BEA がやるとネタですまないかも、と思ったのだけれど、CPU のモードを変えないことが狙いだとすると VMM があったら元の木阿弥なんですよね。BEA がやろうとしていることはちょっと違うんだろうなあ...

                親コメント

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

処理中...