15

バイトコードとネイティブ コード の利点(移植性)を実感しています。

しかし、コードが x86 アーキテクチャで実行されることが常にわかっているとしたら、x86 用にコンパイルしてパフォーマンスを向上させてみませんか?

ネイティブ コードのコンパイルでパフォーマンスが向上すると想定していることに注意してください。一部の人々は、実際には何も得られない可能性があると答えていますが、これは私にとってニュースです..

4

9 に答える 9

15

パフォーマンスの向上 (あるとしても) は、問題に値しないからです。

また、ガベージ コレクションはパフォーマンスにとって非常に重要です。JVM の GC は、たとえばGCJを使用して、コンパイル済みの実行可能ファイルに埋め込まれたものよりも優れている可能性があります。

また、ジャスト イン タイム コンパイルは、コンパイル時にコンパイラよりもコンパイルを最適化するために実行時に利用できる情報が JIT にあるため、パフォーマンスが向上することさえあります。JITのウィキペディアのページを参照してください。

于 2010-02-27T20:27:52.673 に答える
11

「Solaris」はオペレーティング システムであり、CPU アーキテクチャではありません。実際のマシンにインストールされた JVM は、ネイティブの CPU 命令にコンパイルされます。Solaris は、SPARC、x86、または x86-64 アーキテクチャーである可能性があります。

また、JIT コンパイラーは、使用している実際の CPU ファミリーに応じて、プロセッサー固有の最適化を行うことができます。たとえば、さまざまな命令シーケンスは AMD CPU よりも Intel CPU の方が高速であり、正確なプラットフォーム用の JIT コンパイラはこの情報を利用して、高度に最適化されたコードを生成できます。

于 2010-02-27T20:28:49.140 に答える
7

バイトコードは、(たとえば) Solaris 用にコンパイルされJava 仮想マシンで実行されます。そのオペレーティングシステム用に最適化されます。

実際のケースでは、メモリ管理などのために仮想マシンのコードを構築することで、実行時に Java コードと同等またはそれ以上のパフォーマンスが得られることがよくあります。そのコードは何年にもわたって進化し、成熟してきました。

JVM 用に構築することには、移植性だけでなく、より多くの利点があります。たとえば、新しい JVM がリリースされるたびに、コンパイルされたバイトコードは、最適化、アルゴリズムの改善など、ビジネスで最高のものから得られます。一方、C コードをコンパイルしたら、それで終わりです。

于 2010-02-27T20:25:00.130 に答える
5

Just-In-Time コンパイルを使用すると、わずかなパフォーマンス上の利点があるためです。

実際、多くのことを JIT の方が高速に実行できます。

于 2010-02-27T20:25:24.223 に答える
4

実行後、すでに JIT によって Solaris ネイティブ コードにコンパイルされます。対象サイトにアップロードする前にコンパイルすると、それ以外の特典を受けることができません。

于 2010-02-27T20:27:01.037 に答える
4

パフォーマンス上の利点が得られる場合と得られない場合があります。ただし、パフォーマンスが低下する可能性が高くなります。JIT 最適化は静的コンパイルでは不可能であるため、パフォーマンスは、コンパイラーが「目隠し」できる程度のパフォーマンスしか得られません (実際にプログラムをプロファイリングし、それに応じて最適化する必要はありません)。 HotSpot などの JIT コンパイラー)。

コンパイルが (リソースに関して) 安価であり、実行中のプログラムを観察するだけで自動的に最適化できることは、直感的に非常に驚くべきことです。黒魔術ですが、私たちにとっては良いことです:-)

于 2010-02-27T20:29:43.227 に答える
1

JIT に関するこのすべての話は、ところで約 7 年ほど古いものです。現在関係している技術は HotSpot と呼ばれ、単なる JIT ではありません。

于 2010-02-28T06:20:38.273 に答える
1

「x86用にコンパイルしてみませんか」

その場合、実行される特定の CPU の特定の機能を利用できないためです。特に、「x86 用にコンパイルする」を「386 とその子孫で実行できるネイティブ コードを生成する」と読む場合、結果のコードは mmx 命令と同じくらい古いものにも依存できません。

そのため、最終的には、実行するアーキテクチャごとにコンパイルする必要があり (まだ存在しないアーキテクチャについてはどうすればよいでしょうか)、配置する実行可能ファイルをインストーラに選択させる必要があります。または、インテル C++ コンパイラーは、使用される CPU 機能のみが異なる同じ関数の複数のバージョンを生成し、CPU が使用可能であると報告するものに基づいて実行時に適切なものを選択すると聞いています。

一方、バイトコードを「半分コンパイルされた」ソースとして表示できます。これは、ネイティブ コンパイラが (要求されない限り) 実際にはディスクに書き込まない中間形式と同様です。ランタイム環境は、使用されるアーキテクチャを正確に把握して、最終的なコンパイルを実行できます。これは、一部の C#/.net コードが、一部のベンチマークで CPU を集中的に使用するタスクで C++ コードよりもわずかに優れている可能性がある理由です。

バイトコードの「最終コンパイル」では、(静的コンパイルの観点から)明らかに安全ではない追加の最適化仮定を作成し、後でそれらの仮定が間違っていることが判明した場合に再コンパイルすることもできます。

于 2011-03-24T14:20:21.607 に答える
0

JIT (ジャスト イン タイム) コンパイルが非常に高度だからだと思います。

于 2010-02-28T06:43:17.493 に答える