コンテンツにスキップ

Javaの性能

リンクを編集
出典: フリー百科事典『ウィキペディア（Wikipedia）』

これはこのページの過去の版です。Javaden (会話 | 投稿記録) による 2009年7月4日 (土) 06:43 （個人設定で未設定ならUTC）時点の版 (en:Java performance（2009年6月24日 4:31:52(UTC)）より翻訳)であり、現在の版とは大きく異なる場合があります。

(差分) ← 古い版 | 最新版 (差分) | 新しい版 → (差分)
曖昧さ回避 本項ではJavaプラットフォームの性能について述べる。Javaの性能に対する批判や、さらにJavaに対する一般的な批判は、Javaに対する批判を参照のこと

Java とCやC++、Object Pascalといったネイティブコードへのコンパイル言語との性能を客観的に比較することは難しく、論争を巻き起こすテーマである。Java は C++ と似たプログラミング言語であるが、コンパイラが対象とするプラットフォーム はJavaプラットフォームであり、Java仮想マシン上に実装されている。一方 C/C++、Object Pascal のプログラムは特定のハードウェアとOS向けにコンパイルされる。大きく異なるアプローチである静的コンパイルと動的コンパイル/再コンパイルの比較、すなわち実行環境に対する正確な情報が利用できるかどうかが異なるもの比較であるため、比較が困難なシナリオが生じる。

コンパイルされたJavaコードの性能は、プラットフォームの JVM が特定のタスクをどの程度賢く実行するか、また JVM がどの程度ハードウェアやOSの機能を使いこなせるかに依存する。ゆえに Java の性能テストやその比較結果には、使用された JVM のバージョン、開発元、OS、ハードウェアアーキテクチャが明示されていなければならない。同様に、等価なコンパイラ言語のプログラムも、生成された機械語コードの品質に依存する。したがって、性能テストやその比較結果には、コンパイラの名前、バージョン、開発元や、利用された最適化オプションが明示されなければならない。

Java で記述されたプログラムは、C、C++といったコンパイラ言語のプログラムと比較して、低速で大量のメモリを消費すると言われてきた。

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

仮想マシンの最適化手法

様々な最適化技術によりJava仮想マシンの性能は徐々に向上してきたが、Java はいくつかの最適化技術を実装した最初の仮想機械であることも多く、そうした技術は類似のプラットフォームでも使用されている。

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

→「ジャストインタイムコンパイル方式」および「HotSpot」を参照

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

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

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

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

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

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

適応的最適化

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

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

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

ガベージコレクション

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

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

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

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

その他の最適化技術

バイトコード検証の分割

クラスの実行に先立ち、Sun の JVM はバイトコードの検証を行う。バイトコードのロードと検証は特定のクラスがロードされ実行する準備ができた場合のみ行われ、プログラムの開始時点で行われるわけではない（Sun 以外のJVM、たとえば IBM System i 用の Java/400 のように、検証の作業の大半を前もって行い、クラスを検証した情報をキャッシュしておくものもある)。しかし、Java のクラスライブラリも正規の Java クラスであり、使用時にロードされるため、Java プログラムの起動時間は例えばC++のプログラムより長くなることが多い。

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

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

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

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

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

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

  • プログラムがタスクを実行中にもユーザーが操作できるようにすることで、ユーザーに与える印象を改善する
  • マルチコアのアーキテクチャを活かして、二つの関連のない作業を異なるコアで同時に実行する

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

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 では、コードブロックやロックは必要なときだけロックされるようになり[2] [3]、上記の例では仮想マシンは Vector オブジェクトのロックを行わない。

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

レジスタ割付の改善

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

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

クラスデータの共有

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

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

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

→「Java version history」を参照

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

JDK 1.1.6

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

J2SE 1.2

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

J2SE 1.3

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

J2SE 1.4

Sun が1.3 から1.4 での性能向上をまとめたリンクを参照

Java SE 5.0

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

Java SE 6

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

その他の向上:

Java SE 6 Update 10

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

今後の性能改善点

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

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

他の言語との比較

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

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

プログラムの速度

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

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

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

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

起動時間

Java の起動時間は、膨大な数のクラス（プラットフォームのクラスライブラリの全てのクラスを含む)を使用前にロードしなければならないため、C やC++よりかなり低速であることが多い。

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

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

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

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

メモリ使用量

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

  • Java では各オブジェクトが最低12バイト使用するためオーバーヘッドが存在する。4バイトの整数を格納するオブジェクトとは16バイト消費する。ただし、C++ も仮想関数テーブルのために各オブジェクトに4バイトのポインタを割り当てる[6]。
  • クラスライブラリが（最低でもプログラムが使用する分は）実行前にロードされていなければならない[7]。
  • Java のバイナリと、ネイティブにJITコンパイルしたもの両方がメモリ上に存在する。
  • 仮想マシン自体がメモリを消費する。

三角関数

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

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

Java Native Interface

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

ユーザーインターフェイス

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

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

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

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

脚注

  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. ^ Kawaguchi, Kohsuke ( エラー: この日付はリンクしないでください。). “Deep dive into assembly code from Java”. 2008年4月2日閲覧。
  4. ^ この記事 によれば、インタプリタモードとHotspotで10倍以上性能が向上している。
  5. ^ “The Java HotSpot Virtual Machine, v1.4.1”. Sun Microsystems. 2008年4月20日閲覧。
  6. ^ Nutter, Charles ( エラー: この日付はリンクしないでください。). “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”
  7. ^ IBM DeveleporWorks Library
  8. ^ 例えば、停止時間が大幅に短くなっている。Java で書かれたQuake 2の例を参照Jake2
  9. ^ New Java SE 6 Feature: Type Checking Verifier at java.net
  10. ^ Bug report: new register allocator, fixed in Mustang (JDK 6) b59
  11. ^ Mustang's HotSpot Client gets 58% faster! in Osvaldo Pinali Doederlein's Blog at java.net
  12. ^ Class Data Sharing at java.sun.com
  13. ^ Class Data Sharing in JDK 1.5.0 in Java Buzz Forum at artima developer
  14. ^ “Symantec's Just-In-Time Java Compiler To Be Integrated Into Sun JDK 1.1”. 2009年7月4日閲覧。
  15. ^ “Java gets four times faster with new Symantec just-in-time compiler”. 2009年7月4日閲覧。
  16. ^ STR-Crazier: Performance Improvements in Mustang in Chris Campbell's Blog at java.net
  17. ^ See here for a benchmark showing an approximately 60% performance boost from Java 5.0 to 6 for the application JFreeChart
  18. ^ a b Haase, Chet (2007年5月). “Consumer JRE: Leaner, Meaner Java Technology”. Sun Microsystems. 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. ”
  19. ^ Haase, Chet (2007年5月). “Consumer JRE: Leaner, Meaner Java Technology”. Sun Microsystems. 2007年7月27日閲覧。
  20. ^ Haase, Chet (2007年5月). “Consumer JRE: Leaner, Meaner Java Technology”. Sun Microsystems. 2007年7月27日閲覧。
  21. ^ Campbell, Chris ( エラー: この日付はリンクしないでください。). “Faster Java 2D Via Shaders”. 2008年4月26日閲覧。
  22. ^ Haase, Chet (2007年5月). “Consumer JRE: Leaner, Meaner Java Technology”. Sun Microsystems. 2007年7月27日閲覧。
  23. ^ “JSR 292: Supporting Dynamically Typed Languages on the Java Platform”. jcp.org. 2008年5月28日閲覧。
  24. ^ Goetz, Brian ( エラー: この日付はリンクしないでください。). “Java theory and practice: Stick a fork in it, Part 2”. 2008年3月9日閲覧。
  25. ^ Lorimer, R.J. ( エラー: この日付はリンクしないでください。). “Parallelism with Fork/Join in Java 7”. infoq.com. 2008年5月28日閲覧。
  26. ^ “New Compiler Optimizations in the Java HotSpot Virtual Machine”. Sun Microsystems (2006年5月). 2008年5月30日閲覧。
  27. ^ Humble, Charles ( エラー: この日付はリンクしないでください。). “JavaOne: Garbage First”. infoq.com. 2008年9月7日閲覧。
  28. ^ Coward, Dany ( エラー: この日付はリンクしないでください。). “Java VM: Trying a new Garbage Collector for JDK 7”. 2008年11月15日閲覧。
  29. ^ Python にはPsycoがあるが、扱えるコードが限定されており、また Psyco を利用しても Java より性能が低い(リンク参照)
  30. ^ 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日閲覧。
  31. ^ : 260/250 FPS 対 245 FPS (ベンチマーク結果参照)
  32. ^ “mandelbrot benchmark”. Computer Language Benchmarks Game. 2008年2月16日閲覧。
  33. ^ “Microbenchmarking C++, C#, and Java: 32-bit integer arithmetic”. Dr. Dobb's Journal ( エラー: この日付はリンクしないでください。). 2007年11月17日閲覧。
  34. ^ “Microbenchmarking C++, C#, and Java: 64-bit double arithmetic”. Dr. Dobb's Journal ( エラー: この日付はリンクしないでください。). 2007年11月17日閲覧。
  35. ^ “Microbenchmarking C++, C#, and Java: File I/O”. Dr. Dobb's Journal ( エラー: この日付はリンクしないでください。). 2007年11月17日閲覧。
  36. ^ “Microbenchmarking C++, C#, and Java: Exception”. Dr. Dobb's Journal ( エラー: この日付はリンクしないでください。). 2007年11月17日閲覧。
  37. ^ “Microbenchmarking C++, C#, and Java: Single Hash Map”. Dr. Dobb's Journal ( エラー: この日付はリンクしないでください。). 2007年11月17日閲覧。
  38. ^ “Microbenchmarking C++, C#, and Java: Multiple Hash Map”. Dr. Dobb's Journal ( エラー: この日付はリンクしないでください。). 2007年11月17日閲覧。
  39. ^ “Microbenchmarking C++, C#, and Java: Object creation/ destruction and method call”. Dr. Dobb's Journal ( エラー: この日付はリンクしないでください。). 2007年11月17日閲覧。
  40. ^ “Microbenchmarking C++, C#, and Java: Array”. Dr. Dobb's Journal ( エラー: この日付はリンクしないでください。). 2007年11月17日閲覧。
  41. ^ “Microbenchmarking C++, C#, and Java: Trigonometric functions”. Dr. Dobb's Journal ( エラー: この日付はリンクしないでください。). 2007年11月17日閲覧。
  42. ^ “How fast is the new verifier?” ( エラー: この日付はリンクしないでください。). 2007年5月9日閲覧。
  43. ^ “Math (Java Platform SE 6)”. Sun Microsystems. 2008年6月8日閲覧。
  44. ^ Gosling, James (2005年7月27日). “Transcendental Meditation”. 2008年6月8日閲覧。
  45. ^ W. Cowell-Shah, Christopher (2004年1月8日). “Nine Language Performance Round-up: Benchmarking Math & File I/O”. 2008年6月8日閲覧。
  46. ^ Wilson, Steve; Jeff Kesselman (2001年). “JavaTM Platform Performance: Using Native Code”. Sun Microsystems. 2008年2月15日閲覧。
  47. ^ Kurzyniec, Dawid; Vaidy Sunderam. “Efficient Cooperation between Java and Native Codes - JNI Performance Benchmark”. 2008年2月15日閲覧。
  48. ^ Igor, Kri?nar ( エラー: この日付はリンクしないでください。). “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.”
  49. ^ Brian Amedro, Vladimir Bodnartchouk, Denis Caromel, Christian Delbe, Fabrice Huet, Guillermo L. Taboada ( エラー: この日付はリンクしないでください。). “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.”
  50. ^ Owen O'Malley - Yahoo! Grid Computing Team (2008年7月). “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.”

関連項目

外部リンク

プラットフォーム
オラクルのテクノロジー
プラットフォーム技術
主なサードパーティ技術
歴史
主要なJVM言語
コミュニティ
カンファレンス
組織
人物
「https://ja.wikipedia.org/w/index.php?title=Javaの性能&oldid=26737580」から取得