16

Javaは当初JITの前は低速でしたが、今日のパフォーマンスはC++にかなり近いものです。誰かが2つの言語間で測定可能なパフォーマンス比較を行ったかどうか知りたいですか？ C ++と比較した場合、Javaはどこに足りませんか？ Javaは開発者に多くの生産性の向上をもたらすため、ガベージカレッジ、ポインタの不足などにより、アプリケーションをはるかに迅速に作成できます。たとえば、Firefox、Webkit、Open Officeなどのアプリケーションは、100で作​​成すると、はるかに迅速かつ確実に開発できます。 ％Java、おそらく2倍ですが、開発者はパフォーマンス上の理由からC /C++を選択しています。私が言及したようなアプリケーションのC++と同様に、Javaを実行させることができない場所を誰かが示すことができますか？

理由のために、C++でまだ多くのアプリケーション作業が行われていることを付け加えておきます。これは、主観的な質問以上のものを意味します。抽象化のレベルが高い言語では、パフォーマンスが低下することがよくあります。このペナルティが存在しなかった場合、私たちは皆、高級言語でプログラミングすることになります。C ++と比較してJavaはまだどこで支払いますか？具体的に。

4

13 に答える 13

34

言語にはスピードがありません。Java や C++ の言語仕様では、「プログラムはこのように効率的にコンパイルする必要があります」とは指定されていません。

各言語は、プログラムが実行しなければならないこと、または少なくとも実行するように見えることのリストを指定します。これにより、プログラムの効率に上限が設定される場合がありますが、多くの場合、賢いコンパイラは個々のプログラムでこれらの規則を無視できます。重要なのは、あたかも仕様に従っているかのようにプログラムが動作することだけだからです。関数をインライン化したり、ヒープ データをスタックに移動したりできます。

プログラムのパフォーマンスは、コンパイラ、基盤となるプラットフォーム/ハードウェア、およびプログラム コード自体の 3 つに依存します。

「言語」ではありません。最も近いのはコンパイラです。

いずれかの言語が他方よりも高速になるのには十分な理由があります。C++ は、プログラムの実行を遅くする可能性のある約束をあまりしませんが、Java は JIT されています。つまり、ランタイム情報を利用してコードを最適化できる可能性があります。これは、C++ では簡単に実行できません...仕様には、C++ をjitしてはいけないと書かれています。私が思うに、JVM バイトコードの代わりにネイティブ コードを生成する Java コンパイラもあると思います。

あなたの質問は、実行している特定のコンピューター、各言語の特定のコンパイラ、および各言語でのプログラムの特定の実装がある場合にのみ意味があります。

ガベージ コレクションも素晴らしい例です。もちろん、ガベージ コレクションにはある程度のオーバーヘッドが伴いますが、いくつかの重要なショートカットも可能になります。Java や .NET などのマネージ言語では、ヒープ割り当ては、マネージされガベージ コレクションされるため、非常に安価です。C++ では、もちろん指定されていませんが、実際には、OS が多かれ少なかれ断片化されたメモリ空間でメモリの空きブロックを見つけるためにヒープを走査する必要があるため、通常は非常に低速です。どれが一番速いですか? OSに依存します。コンパイラに依存します。ソースコードに依存します。

ソースコードにも大きな違いがあります。Java プログラムを単純に C++ に移植した場合、それはがらくたのように動作します。C++ は仮想関数をうまく処理できず、通常は代わりに使用できる優れた代替手段を利用できます。C++ ではヒープの割り当てが非常に遅くなる可能性があるため、単純に Java プログラムを再実装するのは非常に非効率的です。また、反対方向に進む場合も同様です。Java に直接移植すると、多くの C++ イディオムが不必要に遅くなります。では、1 つのプラットフォームと 1 つのコンパイラーに落ち着いたとしても、プログラムのパフォーマンスをどのように比較しますか? コンパイラーに渡すためにも、その実装を 2 つ作成する必要があり、それはもはや同じプログラムではありません。

しかし、ほとんどの最新のハードウェアでは、最新の Java コンパイラーと最新の C++ コンパイラーを使用して、ほとんどのプログラムを非常に効率的に実装でき、十分に高速であると言っても過言ではありません。ただし、使用している言語を理解し、そのルールに従ってプレイする場合に限ります。C++ で Java コードを書こうとすると、魔法のように Java の方がはるかに効率的であることが判明し、逆もまた同様です。

あなたの質問に対する最も簡潔な答えは、「いいえ。C++ と Java のパフォーマンスの違いを定量化できる人はいません」だと思います ;)

于 2008-11-24T09:24:07.653 に答える
16

JIT コンパイラは、コードの実行時プロファイリングを利用できるため、多くの個々のコード構造に対して高速になる可能性があります。

たとえば、VonC はこの質問への回答で、すべてのオブジェクトのヒープ割り当てについて言及しています。これは実際には正しくありません。JIT は、オブジェクトへの参照がスタック フレームより長く存続しないことをエスケープ分析によって証明できる場合、スタックにオブジェクトを割り当てることができます。このようにして、コンパイラーはスタック割り当てのパフォーマンス上の利点を得ることができ、プログラマーは想定された GC ヒープ割り当ての安全性を保証できます。

同様に、Uri は仮想関数 (ほとんどの非 C++ 言語では仮想メソッドと呼ばれます) について言及しています。これは、JIT コンパイラーが事前 (AOT) コンパイラーではほとんど利用できない利点を持っている別のケースです。その特定の呼び出しサイトはたまたまモノモーフィックです (つまり、実際の型は常に同じです)。すべての仮想メソッド呼び出しの最大 95% が実際にはモノモーフィックであることが判明したため、これは非常に大きな利点となる可能性があります。また、実行時のコードの読み込みによって実行時の特性が変化する可能性があるため、AOT コンパイラがこれを利用するのは困難です。動的に。

于 2008-11-24T05:28:58.063 に答える
12

Pax と Uri の回答を完成させるために、最近のベンチマークをいくつか示します。

前述のように、これらは 2 つの非常に異なる言語であり、次の理由により、 Java は C++ よりも遅くなると確信している人もいます。

  • すべてのオブジェクトのヒープ割り当て(イテレータのような小さなものも含む)
  • 多くの動的キャスト
  • メモリ使用量の増加

[ユーモア]

「Java はハイ パフォーマンスです。ハイ パフォーマンスとは、適切であることを意味します。適切とは、遅いことを意味します。」ミスター・バニー

コメントでdribeasが述べたように、ヒープ割り当ては適切な議論ではありません。
この「アーバン パフォーマンスの伝説、再訪」では次のように述べられています。

「ガベージ コレクションは、直接メモリ管理ほど効率的ではありません。」そして、ある意味で、これらのステートメントは正しいです。動的メモリ管理はそれほど高速ではありません。多くの場合、かなり高速です。
malloc/free アプローチは一度に 1 つのメモリ ブロックを処理しますが、ガベージ コレクション アプローチは大きなバッチでメモリ管理を処理する傾向があり、最適化の機会が増えます (予測可能性がいくらか失われます)。

于 2008-11-24T05:10:38.290 に答える
9

さらに別のベンチ:銃撃戦

于 2008-11-24T07:39:40.640 に答える
7

多くの人が忘れているのは、JIT 手法はあらゆる種類のバイナリ (C++ コンパイラによって生成されたものも含む) に適用できるということです。Java の JIT コンパイルの利点のほとんどは、HP の Dynamo (実行可能ファイルを実行してエミュレートするネイティブ チップよりも高速に実行可能ファイルを実行するエミュレーター) のようなものを使用する場合、C++ でも有効です。ランタイム プロファイリングは、実際には Java のパフォーマンス上の利点ではなく、一般的な JIT コンパイルの利点です。

于 2008-11-24T13:26:00.287 に答える
7

多くの点で、これはリンゴとオレンジを比較するようなものです。

C++ は、使用しないものにはコストを支払わないという考えに基づいて構築されています。メモリを自分で管理する場合、仮想関数を使用しない場合など。

Java はその自由を与えてくれません。それはあなたが望まないかもしれない機能を提供します。自分でメモリを割り当てたい場合は、すべてにヒープ オブジェクトを使用する必要があるため、ガベージ コレクションの影響を受けます。

GUI について話し始めると、UI フレームワークやツールキットが異なればパフォーマンスの問題も異なるため、比較はさらに難しくなります。たとえば、Swing/AWT は通常、ネイティブ OS 用に直接作成されたものよりも遅くなります。C++ では、真に移植可能なツールキットなどを見つけることはめったにありません。

開発者が openoffice を始めたとき、Java ははるかに遅く、UI ツールキットは遅くて見苦しかったと思います。Eclipse のようなツールは、Java でも比較的優れた UI を構築できることを証明していますが、SWT はネイティブ レベルで多くのことを行うツールキットであることは確かです。

于 2008-11-24T05:01:16.030 に答える
6

私にとって、この質問はちょっとしたニシンです (おそらく意図的ではありません)。本当に間違った質問です。

最初に尋ねる質問はこれらです

  1. プログラムを遅くしている原因は何ですか?
  2. 新しいプログラムの場合、重要なパフォーマンス設計の考慮事項は何ですか?

ここにいくつかの良い「なぜ」の質問があります

  • 不要な I/O が多すぎませんか?
  • メモリの使用量が多すぎませんか?
  • メモリ アロケータがスラッシングされているか (割り当てが多すぎる、粒度の細かいオブジェクトが多すぎる)
  • 私のプログラムはネットワーク I/O で長時間ブロックされていますか?
  • 間違った場所にロックがありますか

最初にパフォーマンス (小さな「p」) の側面ではなく、プログラムのパフォーマンスの側面 (大文字の「P」)に本当に集中する必要があると思います。言語が邪魔になるポイントにたどり着くことができれば、パフォーマンスに関してそのポイントまで本当に良い仕事をしたことになります。

新しいコードの場合 - パフォーマンスと効率を前もって計画することが重要です。私は常に、パフォーマンスと効率性を他の機能と同じように扱うことをお勧めします (それらは機能です): UI の輝きや信頼性と同じです。 もちろん、これは多くのことに依存しますが、重要な場合は事前に計画する必要があります。

  • データセットと予想されるスケーリングに適したデータ構造とアルゴリズムを選択する
  • 必要に応じてマルチスレッド UI ベースのアプリ (UI スレッド、バックグラウンド/処理スレッド)
  • 長いネットワーク I/O 待機時間を計画する
  • 前もって目標を設定し、パフォーマンスを測定する計画を立てる - 回帰テストを定期的に実行する
  • メモリ使用量を測定する - メモリの浪費は遅いです (japes を始めましょう :) )
  • イベント、コールバック、またはその他の通知メカニズムがある場合はポーリングしないでください

私がこれをニシンだと思う理由は、C++ と Java のどちらかを選択できる人はめったにいないからです。これらは非常に異なる言語であり、実行時間が非常に異なります。何らかの形であなたを押し付ける他の制約があることはより一般的だと思います-これらは言語パフォーマンスよりも高次の要因になるでしょう。既存のコードとの互換性、既存スタッフのスキルと経験など。

環境も違います。たとえば、Java が未亡人クライアント (対 Web) アプリケーションの正しい選択になることはほとんどありません。逆に、ネイティブ C++ が Web ベースのアプリに選択されることはほとんどありません。（注意してください、私はWindowsの男です-* nixでは状況が非常に異なる場合があります）。

于 2008-11-24T05:22:42.447 に答える
5

私は、パフォーマンスに敏感なアプリケーション（物理シミュレーション、財務モデル）をCとJavaの両方で実装しました。現実には、実装を微調整するよりもアルゴリズムを変更することで、パフォーマンスが常に大幅に向上しますが、実装も重要です。今のところ、JavaはCよりも遅いと思います（C ++での数値の経験はあまりありません）が、注意深く調整することで多くのことが得られます。Javaでは、この調整がはるかに簡単です。セグメンテーション違反、ダブルフリーなどに対処する必要はありません。最新のC ++技術（スマートポインター、テンプレート、STLコンテナー）は使用の速度と相対的な安全性の両方を提供するため、C++はここで中立的な立場を占めます。

于 2009-06-22T21:03:25.347 に答える
5

いつでも JNI に戻して Java からネイティブの速度を得ることができるという単純な事実のために、C++ が常に Java よりも有意に高速であることを証明できる人は誰もいないと思います。

たとえば、SWT を参照してください。これは、Swing を置き換え、ネイティブのパフォーマンスとルック アンド フィールの両方を提供することを意図した、IBM によって構築された (私が思うに) グラフィカル ツールです。

私は、速度よりも開発の容易さを好みます。特に、その速度を得ることができる場合は、最小限の開発時間の方が生のアプリケーションの速度よりも重要であると考えているためです。Java の開発の容易さとコンパイルされた言語の速度。

于 2008-11-24T05:02:46.933 に答える
5

考慮すべきいくつかの点:

  • より優れた C++ コンパイラを入手しても、コードは高速になりません。最初に再コンパイルする必要があります。より優れた JVM を入手すると、すべての Java コードがより高速に実行されます

  • より優れた C++ コンパイラ/JVM を入手すると、通常はコーナー ケースで 10 ～ 20% 高速な実行が見られます。必要なものを達成するためのより優れたアルゴリズムを見つけた場合、1,000% から 10,000%、場合によってはそれ以上のパフォーマンスを簡単に得ることができます。

したがって、今日、パフォーマンスが問題である場合は、次の 2 つの事実を確認する必要があります。

  • この言語では、あるアルゴリズムを別のアルゴリズムに簡単に置き換えることができますか? (別名「リファクタリング」)
  • どのくらいの速度でコードを記述できますか?

それ以外はただの FUD です。

于 2008-11-24T09:55:22.940 に答える
3

C++ と比較した場合、Java はどこが劣っていますか?

素晴らしい質問です。Java と JVM には、C++ と比較してパフォーマンスを低下させる 2 つの主な欠点があります。

  • 型消去に基づくジェネリック。

  • 値型の欠如。

前者は、一般的なコードがボックス化とボックス化解除を引き起こし、大量の不要な割り当てと、キャッシュに適していない余分なレベルの間接化が発生することを意味します。

後者は、プログラマーが複素数 (float のペア)、ハッシュ テーブル エントリ (キーと値のペア)、頂点データなどの任意のデータ構造をアンボックスできないことを意味します。

これらの問題の両方が組み合わさって、Java で効率的な汎用ハッシュ テーブルを実装することが不可能になります。特に、.NET はこれらの問題の両方を解決しました。たとえば、Java の一般的なハッシュ テーブルは、.NET よりも 17 倍遅くなる可能性がありますDictionary。

さらに、JVM の FFI は C++ に比べて非常に低速です。Java から外部 C 関数を呼び出すだけで 1,000 サイクルかかると聞いたことがあります。

于 2010-07-01T23:37:13.690 に答える
1

Javaアプリには、C++プログラムにはない初期化オーバーヘッドがあります。JITを実行すると、C++プログラムほどマイクロ最適化されません。また、実行時のオーバーヘッドはわずかです（GC +間接呼び出しのオーバーヘッド）。全体として、これらの定量化可能な違いは、それほど多くはありません。だが...

Javaアプリを最初に起動するときは、フラックスコンデンサをアクティブにして、環境を1995年に戻す必要があることはよく知られています。これにより、起動に少し遅延が生じます。しかし、それが終わると、JVMは1995年からハードウェア上で実行されている同等のC++プログラムとほぼ同じように動作します。

于 2009-10-25T02:19:27.717 に答える
1

Java、C#、または任意のマネージ プログラミング言語で構築したほうがよいものもあります。他のものは、アンマネージ プログラミング言語 (C や C++ など) を使用して常により適切に構築されます。

通常、前者のカテゴリには一般的な「アプリケーション」が含まれ、2 つ目のカテゴリには一般的な「プラットフォーム」が含まれます。

Java で FireFox や WebKit を構築することは、単純にばかげているだけでなく、最終製品が非常に遅くなり、品質が低下し、エンド ユーザーにとって多くのリソースが浪費されます。Open Office は、おそらく Java、C#、またはSmallTalkの有力候補です。しかし、FireFox や WebKit を Java (または C#) で構築することは、単純にばかげており、失敗が保証されています...

C++ と C は、メモリの一部を使用するだけでなく、多くのことで桁違いに高速になります。仕方ないよ。Java と C# が「マネージド」プログラミング言語である限り、これは決して変わりません。いつの日か、CPU が「問題にならない」ほど高速になるかもしれません。しかし、より多くのCPUが与えられると、人々は要求を柔軟にする傾向があるため、私はそれを疑っています...

ブラウザを構築したい場合は、申し訳ありませんが、C または C++ を独学する必要があります ;)

于 2008-11-24T08:03:20.687 に答える