Wikipedia

Javaの性能

Javaプラットフォームの性能

Javaの性能（ジャバのせいのう）では、Javaプラットフォームの性能について説明する。プログラミング言語としてのJavaに対する批判や、Javaプラットフォームの性能に対する批判は「Javaに対する批判」の記事を参照のこと。この記事ではJavaプラットフォームの性能について批判以外の説明をする。

プログラミング言語Javaは、その「ネットワークから送り込まれるプログラムの安全な実行」や「write once, run anywhere」というスローガンを、業界にありがちなスローガンだけのスローガンではなく可能な限り達成するべく、Javaバイトコードにコンパイルするコンパイラと、Javaバイトコードを解釈実行するインタプリタであるJava仮想マシン (Java VM, JVM)、という構成の実装を、公式の実装として伴って発表された。

コンピュータ科学的には特に目新しいものではない。しかし、従来のC言語あるいはC++といったネイティブコードにコンパイルする言語で書かれたアプリケーションソフトウェアとの性能比較や、当初はJVMのチューニングや高速化手法が進んでいなかったことによる性能の制限、また、当時の一般ユーザーが使っていたMicrosoft Internet Explorerにおいて、Javaアプレットが埋込まれたウェブページを表示しようとすると、JVMを起動するために数十秒から最悪の場合は数分も待たされたことから（起動してしまえば実は高性能なVMだったのだが）、「Javaは遅い」などと言われるようになったため、「Javaの性能」が議論されるようになった。

Javaプログラムの実行速度はJITコンパイルの導入（1997年 / 1998年のJava 1.1以降）や [1][2] 、 コードの解析の機能が言語に追加されたこと、Java仮想マシン自体の最適化（2000年からサン・マイクロシステムズのVMで標準的に動作するようになったHotSpot技術など）によって大きく向上した。

仮想マシンの最適化手法

編集

オラクル（旧サン・マイクロシステムズ）のJVMの性能は徐々に向上してきたが、このJVMはいくつかの最適化を実装した最初の仮想機械であることも多く、そうした技術は類似のプラットフォームでも使用されている。

ジャストインタイムコンパイル

編集
→「実行時コンパイラ」および「HotSpot」を参照

初期のJava仮想マシンはバイトコードのインタプリタであり、このことが性能に対する大きな足かせ（平均的なアプリケーションで、Java対Cで10〜20倍程度）になっていた[3]。

Java 1.1で JIT コンパイラが導入された。

Java 1.2でHotSpotと呼ばれる技術が導入された。これは、Java仮想マシンがプログラムの頻繁に実行される箇所、「ホットスポット」の性能解析を実行中に実行し続けるもので、解析した情報は最適化に利用して、他のパフォーマンスに影響のないコードには余分な負荷をかけることなく、性能を向上させることができる。

Java 1.3でHotSpotが標準で用いられるようになった。

HotSpot技術により、コードはまずインタプリタ実行され、「ホットスポット」が動的にコンパイルされる。Javaの性能測定においてベンチマークをとる前にプログラムを数回実行させる必要があるのはこのためである。

HotSpotによるコンパイルではインライン展開、ループ展開、境界チェックの省略、アーキテクチャ固有のレジスタ割り付けなどの様々な最適化手法が用いられる[4]。 ベンチマークによってはこうした手法により10倍の性能向上が見られる[5]。

適応的最適化

編集
→「適応的最適化」を参照

適応的最適化 (adaptive optimization) とは、計算機科学においてプログラムの一部を現在の実行結果のプロファイルに基づき動的再コンパイル (dynamic recompilation) する技術である。単純な実装では、適応的最適化はジャストインコンパイルとインタプリタ実行を選択するだけだが、より高水準のものでは、データの局所的な状態を用いて分岐を取り除き、インライン展開してコンテキスト切り替えを削減することもできる。

HotSpotのようなJava仮想マシンは、一度JITコンパイルされたコードを解消 (deoptimization: 脱最適化) することも可能である。これによって、積極的な（場合によっては危険な）最適化を実行し、後で最適化を解消し安全な実行方法に戻ることもできる[6][7]。

ガベージコレクション

編集
→「ガベージコレクション」を参照

Java 1.0と1.1のJava仮想マシンでは、ガベージコレクション実行後のヒープが断片化する可能性のあるマーク・アンド・スイープ方式のガベージコレクションを採用していた。

Java 1.2より、Java仮想マシンは世代別ガベージコレクションを用いるようになり[8]、断片化が起こりづらくなった[9]。

現代的なJava仮想マシンは、ガベージコレクションの性能を改善する様々な手法を用いている[10]。

その他の最適化技術

編集

バイトコード検証の分割

編集

クラスの実行に先立ち、オラクルのJVMはバイトコードの検証を行う。バイトコードのロードと検証は特定のクラスがロードされ実行する準備ができた場合のみ行われ、プログラムの開始時点で行われるわけではない[11]。しかし、Javaのクラスライブラリも正規のJavaクラスであり、使用時にロードされるため、Javaプログラムの起動時間は例えばC++のプログラムより長くなることが多い。

分割検証と呼ばれる技術がJavaプラットフォームのJ2MEで導入され、Java version 6からJava仮想マシンで利用されるようになった。これはバイトコードの検証を二つのフェーズに分割する[12]。

  • 設計時 - ソースコードからバイトコードにクラスをコンパイルする際
  • 実行時 - クラスをロードする際

こうした手法は、Javaコンパイラがクラスのコードの流れを解析し、コンパイルされたメソッドのバイトコードにクラスのフロー情報の概要を注釈(アノテート)することで動作する。実行時の検証を劇的に単純化するわけではないが、若干の処理を省略することができる。

エスケープ解析と粗粒度ロック

編集
→「ロック_(情報工学)」および「エスケープ解析」を参照

Javaは言語レベルでマルチスレッドに対応している。マルチスレッドとは、下記のようなことを可能にする技術である。

  • 並行コンピューティング - 例えばプログラムがバックグラウンドでタスクを実行中であってもユーザーがGUIを操作できるようにすることで、応答性やユーザーに与える印象を改善する
  • 並列コンピューティング - 例えばマルチコアプロセッサのアーキテクチャを活かして、依存関係のない複数の作業を異なるコアで同時に実行し、処理時間を削減する

しかし、マルチスレッドを使用するプログラムは、スレッド間で共有されるオブジェクトやメソッド、コードブロックに開発者が特別な注意を払う必要がある。またオブジェクトやコードブロックをロックすることは、それに伴うOSの性質によって時間のかかる操作である（並行性制御やロックの粒度を参照）。

Javaライブラリにはどのメソッドが複数のスレッドから使用されるか分からないため、マルチスレッド環境で使用される標準的なライブラリは常にコードブロックのロックを行っている。

Java 6以前では、複数の異なるスレッドが同時にオブジェクトを変更するリスクがない場合でも、仮想マシンはオブジェクトやコードブロックのロックをプログラムの要求にしたがって行っていた(ロックの実装を参照)。例えば、ローカル変数のVectorがあり、それに対する add 操作を行う際、それが確実にローカルでしか使用されずロックが不要である状況でも、同時に他のスレッドから変更されないようロックを行っていた。 

public String getNames() {
    Vector v = new Vector();
    v.add("Me");
    v.add("You");
    v.add("Her");
    return v.toString();
}

Java 6では、コードブロックやロックは必要なときだけロックされるようになり[1] [2]、上記の例では仮想マシンはVectorオブジェクトのロックを行わない。

バージョン 6 Update 14で、Javaは実験的ながらエスケープ解析をサポートするようになった[3]。

レジスタ割付の改善

編集

Java 6以前では、「クライアント」仮想マシンにおけるレジスタ割り付けはかなり初歩的なもので（ブロックを超えてレジスタが生存できない）、これは例えばx86のようなレジスタが少ないアーキテクチャで問題となる。ある操作に必要なレジスタが足りなくなると、コンパイラはレジスタからメモリ（ないしはメモリからレジスタ）に値をコピーするが、メモリは通常レジスタより低速なので、通常より時間がかかる。なお「サーバ」仮想マシンではグラフ彩色によるレジスタ割り付けを行うため、こうした問題は生じない。

レジスタ割り付けの最適化はサンのJDK 6で導入された[13]。これは同じレジスタを、可能な場合コードブロックをまたがって使用することでメモリアクセスを減らすもので、報告によればいくつかのベンチマークで約60%の性能向上が得られた[14]。

クラスデータの共有

編集

オラクルJVMにおけるクラスデータの共有 (class data sharing: CDS) とは、Javaアプリケーションの起動時間を短くし、同時にメモリ使用量を削減する仕組みである。JREがインストールされると、インストーラーはシステムJARファイル（Java のクラスライブラリを全て含むJARファイルで、rt.jarと呼ばれる）からいくつかのクラスを特別な内部表現形式でロードし、この内部表現を「共有書庫」ファイルとして書き出す。それ以降のJVMの呼び出し時には、共有書庫ファイルはメモリマッピングされ、これによってクラスをロードする時間を短縮し、複数 JVM プロセスがこれらのクラスのメタデータを共有できるようになる[15]。

起動時間の短縮は、特に小さなプログラムで効果が著しい[16]。

Sun の Java バージョンによる性能の向上

編集
→「en:Java version history」を参照

上記以外にも、オラクルのJavaは各バージョンでJava APIの性能向上を多数盛り込んでいる。

JDK 1.1.6

編集

仮想マシンレベルの向上:

J2SE 1.2

編集

仮想マシンレベルの向上:

J2SE 1.3

編集

仮想マシンレベルの向上:

J2SE 1.4

編集

サン・マイクロシステムズが1.3から1.4での性能向上をまとめたリンクを参照

Java SE 5.0

編集

仮想マシンレベルの向上:

Java SE 6

編集

仮想マシンレベルの向上:

その他の向上:

Java SE 6 Update 10

編集
  • Java Quick Starterにより、OS起動時にJRE のデータをディスクキャッシュにロードしておくことでアプリケーションの起動時間を短縮する[21]。
  • プラットフォームの一部で、アプリケーションを実行する際に必要な部分もWebからダウンロードされるようになった。JRE全体のサイズは12MBになり、典型的なSwingアプリケーションは4MBしか使用しない。残りはバックグラウンドでダウンロードされる[22]。
  • Direct3Dが標準で使用されるようになり、Windows上でのグラフィック性能が向上した[23]。複雑なJava 2Dの操作を高速化するためGPUのシェーダーを使用するようになった[24]。

今後の性能改善点

編集

今後の性能改善は、Java 6のupdateかJava 7で計画されている[25]。

  • JVMでの動的プログラミング言語のサポート。Multi Language Virtual Machineのプロトタイプ開発に基づく[26]。
  • 並列性を提供するライブラリの改善。マルチコアプロセッサ上での並列処理を行う[27][28]
  • 多段コンパイルと呼ばれる手法で、Java仮想マシンがクライアントとサーバという二種類のJITコンパイルの両方を、同じセッションで使用できるようにする[29]。
    • クライアントのJITコンパイルは、起動時に使用される（起動時と小規模なアプリケーションに適しているため）
    • サーバーのJITコンパイルは、長時間動作するアプリケーションに使用される（クライアントより性能がよいため）
  • 既存の並列化されたガベージコレクタ (CMS collector; Concurrent Mark-Sweep collector) を、停止時間が一定であることを保証した新しい G1 (Garbage First) コレクタに置き換える[30][31]。

他の言語との比較

編集

Javaプログラムは通常仮想マシンによって実行時にJITコンパイルされるが、 C/C++のように事前コンパイルすることも可能である。JITコンパイルされた場合、その性能は一般的に[4]

  • CやC++などのコンパイル言語と比べて性能は劣る。ただ通常のタスクでは大きな性能の低下はない。
  • C#などの他のJITコンパイルを行う言語と同様の性能を示す。
  • 性能の良いネイティブコードへのコンパイラ（JITあるいはAOT）を持たないPerl、Ruby、PHP、Pythonなどの言語より、大幅に高い性能を示す[32]。

プログラムの速度

編集

Javaプログラムの平均的な性能は徐々に向上しており、Javaの性能はCやC++に匹敵するほどになっており、Javaが低速な場合もあるが、高速な場合もある[33]。2009年3月の時点で、Java は Computer Language Benchmarks GameにおいてC/C++より5-15%遅い。ベンチマークは小規模で数値演算中心の性能を測定するとも言われる。これは、おそらくCに有利に働く。実際のプログラムでは、JavaがCを上回ったり性能の差はなかったりする。例として、Jake2（Quake 2クローンで、GPLのCコードをJavaに変換して作成）のベンチマークがあり、Java 5.0のバージョンは、同じハードウェア構成でCの性能を上回る[34]。データがどのように計測されたか明確ではないが（例えば、オリジナルのQuack 2の実行ファイルが1997年にコンパイルされたものであれば、現在のコンパイラではよりよい最適化を行うことができる）、Javaの同じソースコードがVMを更新するだけで大きく性能向上しており、これは100%静的にコンパイルする方法では達成できない。

また、Javaや類似の言語では可能な最適化で、C/C++では実施できないものもある[33]。

  • C形式のポインタは、ポインタをサポートする言語での最適化を困難にする。
  • コードがプログラムの実行前にコンパイルされるため、#適応的コンパイルは完全にコンパイルされたコードでは実施できず、アーキテクチャの機能や、コードパスを用いた最適化の恩恵を受けられない。いくつかのベンチマークの結果は、C/C++の性能はプロセッサアーキテクチャに対応したコンパイルオプション（たとえばSSE2の利用など）に強く依存しており、JavaプログラムはJITコンパイルにより対象のアーキテクチャに適応できることを示している[35]。
  • エスケープ解析の手法は、オブジェクトがどこで使用されるかをコンパイラが知ることができないため、たとえばC++では使用できない（また、ポインタの使用が原因でもある）。

しかし、JavaとC/C++でのベンチマークによる比較は実施する作業に大きく依存する。例えば、Java 5.0と比較すると、

起動時間

編集

Javaアプリケーションの起動時は、膨大な数のクラス（プラットフォームのクラスライブラリの全て[要出典]のクラスを含む）を使用前にロードしなければならないため、CやC++よりもかなり時間がかかることが多い。

起動時間の大半はJVMの初期化やクラスのロードそのものではなく、I/Oを伴う操作によるものと思われる[独自研究?] (rt.jarのクラスデータファイルは40MBあり、JVMは多数のデータをこの巨大なファイルをシークして取り出さなければならない)[21]。いくつかの実験により、バイトコード検証分割の方法を用いるとクラスのロードは約40%向上するが、大規模なプログラムの起動時間は5%しか向上しないことがわかった[45]。

改善幅は小さいものの、単純な操作を実行しすぐ終了するような小さなプログラムでは、Javaプラットフォームのデータローディングはプログラムの操作の数倍の負荷であるため、向上が目に見えやすい。

Java SE 6 Update 10より、オラクルのJREにはQuick Starterが同梱されるようになり、OSの起動時にクラスのデータをロードしておくことで、ディスクではなくディスクキャッシュからデータを読み出すことができるようになる。

Excelsior JETでは、この問題に対して別の方向からアプローチしている。JETのStartup Optimizerはアプリケーションの起動時にディスクから読み出すデータを削減し、さらにシーケンシャルに読み出せるよう配置する。

メモリ使用量

編集

Javaのメモリ使用量はC/C++より大きい。

  • 32ビット環境のJavaでは各オブジェクトに最低8バイト、各配列に12バイトのオーバーヘッドが存在する（64ビットの環境では倍）。また、オブジェクトのサイズが8の倍数でない場合は、8の倍数に切り上げられる。そのため、4バイトの整数を格納するオブジェクトは32ビット環境で16バイト消費する。ただし、C++も仮想関数テーブルを持つ型は、各オブジェクトに32ビット環境で4バイト、64ビット環境で8バイトのポインタを余分に割り当てる[5]。また、多重継承や仮想継承をするとメンバー関数ポインタのサイズが増大する処理系もある[46]。
  • クラスライブラリが（最低でもプログラムが使用する分は）実行前にロードされていなければならない[6]。
  • Javaのバイナリと、ネイティブにJITコンパイルしたものの両方がメモリ上に存在する。
  • 仮想マシン自体がメモリを消費する。

三角関数

編集

Javaの三角関数の性能は、Cと比べて悪い。Javaが数値演算の結果に（使用するハードウェアとも合致しない場合もある）厳密な仕様を定義している[47]ためである。

x87での絶対値 /4以上の値に対するサイン、コサインの演算結果は、 の値に近似値を用いるため正確ではない[48]。JVMの実装ではソフトウェアで正確な演算を行わなければならず、その領域では大きな性能低下を引き起こす[49]。

Java Native Interface

編集

Java Native Interfaceはオーバーヘッドが大きく、JVM上で動作するコードとネイティブコードの境界を行き来するコストが高くなっている[50][51]。

ユーザインタフェース

編集

Swingはウィジェットの描画をPure Javaで記述されたJava 2D APIに任せているため、ネイティブのウィジェット・ツールキットと比較して低速であるとされてきた。しかし、SwingとOSのネイティブGUIライブラリに描画処理を任せるStandard Widget Toolkitをベンチマークで比較しても、片方が明確に速いわけではなく、結果はコンテキストや環境に大きく依存した[52]。

高性能計算分野での Java の使用

編集

いくつかの独立した研究によれば、高性能計算 (HPC) における Javaの性能は、演算中心のベンチマークでFORTRANと同等であるが、JVMはグリッドネットワーク上の通信が多くなると、スケーラビリティに問題があるようである[53]。

しかし、Javaで記述された高性能計算のアプリケーションがベンチマークで最高の成績を出したことがある。2008年、Javaで記述されたHPCのプロジェクト Apache Hadoop が、テラバイト級の整数のソートで最高速の結果を出した[54]。

脚注

編集
  1. ^ “Symantec's Just-In-Time Java Compiler To Be Integrated Into Sun JDK 1.1”. 2009年7月4日閲覧。
  2. ^ “Apple Licenses Symantec's Just In Time (JIT) Compiler To Accelerate Mac OS Runtime For Java”. 2009年7月4日閲覧。
  3. ^ Performance Comparison of Java/.NET Runtimes (Oct 2004)
  4. ^ Kawaguchi, Kohsuke (2008年3月30日). “Deep dive into assembly code from Java”. 2008年4月2日閲覧。
  5. ^ この記事 によれば、インタプリタモードとHotspotで10倍以上性能が向上している。
  6. ^ “The Java HotSpot Virtual Machine, v1.4.1”. サン・マイクロシステムズ. 2008年4月20日閲覧。
  7. ^ Nutter, Charles (2008年1月28日). “Lang.NET 2008: Day 1 Thoughts”. 2008年4月20日閲覧。 “Deoptimization is very exciting when dealing with performance concerns, since it means you can make much more aggressive optimizations...knowing you'll be able to fall back on a tried and true safe path later on”
  8. ^ Javaの理論と実践: 1.4.1 JVM中のガーベジ・コレクション
  9. ^ Javaの理論と実践: ガベージコレクションとパフォーマンス
  10. ^ 例えば、停止時間が大幅に短くなっている。Java で書かれたQuake 2の例を参照Jake2
  11. ^ オラクル以外のJVM、たとえば IBM System i用のJava/400のように、検証の作業の大半を前もって行い、クラスを検証した情報をキャッシュしておくものもある。
  12. ^ New Java SE 6 Feature: Type Checking Verifier at java.net
  13. ^ Bug report: new register allocator, fixed in Mustang (JDK 6) b59
  14. ^ Mustang's HotSpot Client gets 58% faster! in Osvaldo Pinali Doederlein's Blog at java.net
  15. ^ Class Data Sharing at java.sun.com
  16. ^ Class Data Sharing in JDK 1.5.0 in Java Buzz Forum at artima developer
  17. ^ “Symantec's Just-In-Time Java Compiler To Be Integrated Into Sun JDK 1.1”. 2009年7月4日閲覧。
  18. ^ “Java gets four times faster with new Symantec just-in-time compiler”. 2009年7月4日閲覧。
  19. ^ STR-Crazier: Performance Improvements in Mustang in Chris Campbell's Blog at java.net[リンク切れ]
  20. ^ See here for a benchmark showing an approximately 60% performance boost from Java 5.0 to 6 for the application JFreeChart
  21. ^ a b Haase, Chet (May 2007). “Consumer JRE: Leaner, Meaner Java Technology”. サン・マイクロシステムズ. 2007年7月27日閲覧。 “At the OS level, all of these megabytes have to be read from disk, which is a very slow operation. Actually, it's the seek time of the disk that's the killer; reading large files sequentially is relatively fast, but seeking the bits that we actually need is not. So even though we only need a small fraction of the data in these large files for any particular application, the fact that we're seeking all over within the files means that there is plenty of disk activity. ”
  22. ^ Haase, Chet (May 2007). “Consumer JRE: Leaner, Meaner Java Technology”. サン・マイクロシステムズ. 2007年7月27日閲覧。
  23. ^ Haase, Chet (May 2007). “Consumer JRE: Leaner, Meaner Java Technology”. サン・マイクロシステムズ. 2007年7月27日閲覧。
  24. ^ Campbell, Chris (2007年4月7日). “Faster Java 2D Via Shaders”. 2008年4月26日閲覧。
  25. ^ Haase, Chet (May 2007). “Consumer JRE: Leaner, Meaner Java Technology”. サン・マイクロシステムズ. 2007年7月27日閲覧。
  26. ^ “JSR 292: Supporting Dynamically Typed Languages on the Java Platform”. jcp.org. 2008年5月28日閲覧。
  27. ^ Goetz, Brian (2008年3月4日). “Java theory and practice: Stick a fork in it, Part 2”. 2008年3月9日閲覧。
  28. ^ Lorimer, R.J. (2008年3月21日). “Parallelism with Fork/Join in Java 7”. infoq.com. 2008年5月28日閲覧。
  29. ^ “New Compiler Optimizations in the Java HotSpot Virtual Machine”. サン・マイクロシステムズ (May 2006). 2008年5月30日閲覧。
  30. ^ Humble, Charles (2008年5月13日). “JavaOne: Garbage First”. infoq.com. 2008年9月7日閲覧。
  31. ^ Coward, Dany (2008年11月12日). “Java VM: Trying a new Garbage Collector for JDK 7”. 2008年11月15日閲覧。
  32. ^ Python にはPsycoがあるが、扱えるコードが限定されており、また Psyco を利用しても Java より性能が低い（リンク参照）。
  33. ^ a b Lewis, J.P.; Neumann, Ulrich. “Performance of Java versus C++”. Computer Graphics and Immersive Technology Lab, University of Southern California. 2009年7月4日閲覧。
  34. ^ : 260/250 FPS対245 FPS（ベンチマーク結果参照）
  35. ^ “mandelbrot benchmark”. Computer Language Benchmarks Game. 2008年2月16日閲覧。
  36. ^ “Microbenchmarking C++, C#, and Java: 32-bit integer arithmetic”. Dr. Dobb's Journal (2005年7月1日). 2007年11月17日閲覧。
  37. ^ “Microbenchmarking C++, C#, and Java: 64-bit double arithmetic”. Dr. Dobb's Journal (2005年7月1日). 2007年11月17日閲覧。
  38. ^ “Microbenchmarking C++, C#, and Java: File I/O”. Dr. Dobb's Journal (2005年7月1日). 2007年11月17日閲覧。
  39. ^ “Microbenchmarking C++, C#, and Java: Exception”. Dr. Dobb's Journal (2005年7月1日). 2007年11月17日閲覧。
  40. ^ “Microbenchmarking C++, C#, and Java: Single Hash Map”. Dr. Dobb's Journal (2005年7月1日). 2007年11月17日閲覧。
  41. ^ “Microbenchmarking C++, C#, and Java: Multiple Hash Map”. Dr. Dobb's Journal (2005年7月1日). 2007年11月17日閲覧。
  42. ^ “Microbenchmarking C++, C#, and Java: Object creation/ destruction and method call”. Dr. Dobb's Journal (2005年7月1日). 2007年11月17日閲覧。
  43. ^ “Microbenchmarking C++, C#, and Java: Array”. Dr. Dobb's Journal (2005年7月1日). 2007年11月17日閲覧。
  44. ^ “Microbenchmarking C++, C#, and Java: Trigonometric functions”. Dr. Dobb's Journal (2005年7月1日). 2007年11月17日閲覧。
  45. ^ “How fast is the new verifier?” (2006年2月7日). 2007年5月9日閲覧。
  46. ^ Microsoft Visual C++など。
  47. ^ “Math (Java Platform SE 6)”. サン・マイクロシステムズ. 2008年6月8日閲覧。
  48. ^ Gosling, James (2005年7月27日). “Transcendental Meditation”. 2008年6月8日閲覧。
  49. ^ W. Cowell-Shah, Christopher (2004年1月8日). “Nine Language Performance Round-up: Benchmarking Math & File I/O”. 2008年6月8日閲覧。
  50. ^ Wilson, Steve; Jeff Kesselman (2001年). “JavaTM Platform Performance: Using Native Code”. サン・マイクロシステムズ. 2008年2月15日閲覧。
  51. ^ Kurzyniec, Dawid; Vaidy Sunderam. “Efficient Cooperation between Java and Native Codes - JNI Performance Benchmark”. 2008年2月15日閲覧。
  52. ^ Igor, Kri?nar (2005年5月10日). “SWT Vs. Swing Performance Comparison”. cosylab.com. 2008年5月24日閲覧。 “Initial expectation before performing this benchmark was to find SWT outperform Swing. This expectation stemmed from greater responsiveness of SWT-based Java applications (e.g., Eclipse IDE) compared to Swing-based applications. However, this expectation could not be quantitatively confirmed.”
  53. ^ Brian Amedro, Vladimir Bodnartchouk, Denis Caromel, Christian Delbe, Fabrice Huet, Guillermo L. Taboada (August 2008). “Current State of Java for HPC”. INRIA. 2008年9月4日閲覧。 “We first perform some micro benchmarks for various JVMs, showing the overall good performance for basic arithmetic operations(...). Comparing this implementation with a Fortran/MPI one, we show that they have similar performance on computation intensive benchmarks, but still have scalability issues when performing intensive communications.”
  54. ^ Owen O'Malley - Yahoo! Grid Computing Team (July 2008). “Apache Hadoop Wins Terabyte Sort Benchmark”. 2008年12月21日閲覧。 “This is the first time that either a Java or an open source program has won.”

関連項目

編集

外部リンク

編集
「https://ja.wikipedia.org/w/index.php?title=Javaの性能&oldid=99254102」から取得