- - PR -
.NETはインタプリタじゃない？
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-03-19 13:21
はじめまして。
最近、.NETがわかる本を読みましたが、 .NETはJavaのようなインタプリタでは ないという記述がありました。 JavaもJITコンパイラを使って実行して いると思っていたのですが、それと何か 違いがあるのでしょうか？ さっぱりわかりません。。。(^^;) http://www2.gihyo.co.jp/books/bookinfo.asp?ID=4-7741-1349-2 | ||||||||||||
|
投稿日時: 2002-03-19 14:52
JITコンパイラはコンパイラであって、インタプリタではありません。
JavaでもJITコンパイラでコンパイルされて実行されているときは、ネイティブコードが走っているのであって、インタプリタで走っているわけではありません。 OK? _________________ | ||||||||||||
|
投稿日時: 2002-03-19 15:42
つまり、.NETもJavaもJITコンパイラでコンパイルされながら、
ネイティブコードで走っているので、性能差はそんなにない？ ってことでしょうか？ 私の読んだ本だと、.NETはJavaより高速に動作すると書いて あったので混乱しております。(^^;) Javaと同じであるというなら、Sunも次期Forteでマルチ言語 対応するっていうから、ますます同じですね。(^^;) (日経ITProより) | ||||||||||||
|
投稿日時: 2002-03-19 17:29
インタプリタはソース自体や中間コードを逐次解釈しながら実行します。
Java は当初はバイトコードインタープリタで動作していましたが今では JITコンパイラの方が主流になっています。 Javaソース -> バイトコード -> VM(バイトコードインタープリタ) が Javaソース -> バイトコード -> VM(JITコンパイラ) -> ネイティブコード になったわけです しかしJavaはインタープリタからコンパイラに変わったわけではありません。 バイトコードを生成する時にコンパイルを行っているのでバイトコードインタープリタを使っていても立派なコンパイラです。（Compileは翻訳であり、少しでも受け取り側に容易に解釈できる様に変形するのがコンパイラの仕事です。） 簡単に言えば、C++等の純粋なコンパイル言語では、実行環境でなければわからない事は「無い」と仮定されていますのでネイティブコードを直接生成します。 インタープリタの存在価値はプログラムの中には実行時にしかわからない事があるので実行時にプログラムの解釈を先延ばしし、できるだけの汎用性を得ることです。 JITコンパイラはそれらのいいとこだけを取り出す為に、前段のコンパイラで実行環境に依存しない解釈を完全に済ませた中間コードを生成し、後段のJITで実行環境に合わせた最終コンパイルをしてネイティブコードにします。 JITやバイトコードインタープリタ、MSILなどはCPUに依存しません、前段のコンパイラにとっては実際に実行に使用するCPUでさえ分からないという仮定がされているわけです。 これが、JavaプログラムがSunでもIntelでも携帯でも走る理由です。 そしてマクロな視点で見ればJavaも.Netも解釈実行系の仕組みは対して変わりません Java ソース -> バイトコード -> JavaVM C#ソース -> MSIL -> CLR ソース -> 中間言語 -> 実行エンジン .Net と Java で解釈実行系の仕組みの違いによる理論的な意味での速度差が出るとしたら、PreJITを使うというケースです。 .Netでは一般のJITが実行開始時に動作するのに対して、インストール時にJITでネイティブコードを生成する事や、初めての実行時にJITでネイティブコードを生成させ、次回以降はネイティブコードをキャッシュから取り込むことで再利用する事ができ、このとき、JITの実行負荷が軽減される事によって速度差が生じます。 後は、コンパイラによる最適化の度合いやJITが生成するネイティブコードの質、ランタイムの実装が速度を決める要因ですが、これは言語によって決まることではありません。 C++で GCCとVCで同一ソースをコンパイルしたとしても出来上がるコードの実行速度は違いますし、 Java でも Sun による実装とIBMによる実装では実行速度が違います。 現状ではJava と .Net では、IBM Java > .Net > Sun Javaのようです faster<->slower 個人で試した結果です、あらゆるケースでそうなるとは言いませんし、各実行系のバージョンにもよる事です。 .NetとJavaで比較した結果として.Netの方が早いという本の記述は、Sun Javaと.Netの比較ではないでしょうか？ | ||||||||||||
|
投稿日時: 2002-03-19 18:53
はるほど、大変よくわかりました。
長文の解説に感謝します。 ありがとうございました。 | ||||||||||||
|
投稿日時: 2002-03-20 10:14
JavaのJITterについて詳しくはないんですが、JavaのHotspotコンパイラは、コードを解析して、よく使われるメソッドをコンパイルして実行することで、コンパイル時間(これはJITterでは実行時間に含まれてしまう)の短縮と、コンパイルによる実行速度の改善との両立を目指しているようです。 一方、CLRはコードをメソッド単位でコンパイルします。メソッドが呼ばれたらコンパイルし、次からはコンパイル済みのものを使うようにします。 JavaのHotspot以前のJITterは、Hotspotという技術の登場から推測するに、実行時にすべてをコンパイルしていたのではないでしょうか？ この3者の仕組みの違いは理論的に速度に影響を与えると思います。
これはngen.exeのことだと思いますが、
これは初耳です。どこかにリファレンスがありますか？ | ||||||||||||
|
投稿日時: 2002-03-20 10:46
おそらく、最初の実行時にコンパイルされ、次回以降はキャッシュされたものが 利用される、というやつだと思われます。 | ||||||||||||
|
投稿日時: 2002-03-20 12:12
>おそらく、最初の実行時にコンパイルされ、次回以降はキャッシュされたものが
>利用される、というやつだと思われます。 というやつ、とは？ | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。