私の理解では、C/C++ は特定のマシン アーキテクチャで実行するネイティブ コードを生成します。逆に、Java や C# などの言語は、ネイティブ アーキテクチャを抽象化する仮想マシン上で実行されます。論理的には、Java や C# がこの中間ステップのために C++ の速度に匹敵することは不可能に思えますが、最新のコンパイラ (「ホット スポット」) はこの速度を達成できるか、それを超えることさえあると言われています。
おそらく、これは言語の問題というよりもコンパイラの問題ですが、これらの仮想マシン言語の 1 つが母国語よりも優れたパフォーマンスを発揮できる理由を平易な英語で説明できる人はいますか?
以前の投稿で既に述べたように、JIT は実行時に IL/バイトコードをネイティブ コードにコンパイルできます。そのコストは言及されましたが、結論にはなりませんでした。
JIT には、すべてをコンパイルできないという大きな問題があります。JIT コンパイルには時間がかかるため、JIT はコードの一部のみをコンパイルしますが、静的コンパイラは完全なネイティブ バイナリを生成します。コンパイラは、JIT よりも簡単に優れたパフォーマンスを発揮します。
もちろん、C# (または Java、または VB) は通常、実行可能で堅牢なソリューションを生成するのに C++ よりも高速です (C++ には複雑なセマンティクスがあり、C++ 標準ライブラリは興味深く強力ですが、完全なライブラリと比較すると非常に貧弱です)。通常、C++ と .NET または Java JIT の違いはほとんどのユーザーにはわかりません。重要なバイナリについては、C++ 処理を呼び出すことができます。 C# または Java から (この種のネイティブ呼び出し自体が非常にコストがかかる場合でも)...
通常、C++ ランタイム コードを C# または Java の同等のコードと比較していることに注意してください。しかし、C++ には、すぐに Java/C# を凌駕できる機能が 1 つあります。それは、テンプレート メタプログラミングです。コード処理はコンパイル時に行われ (したがって、コンパイル時間が大幅に増加します)、実行時間がゼロ (またはほぼゼロ) になります。
私はまだこれに対する実際の影響を見てきました (私は概念だけで遊んでいましたが、その時までに、違いは JIT の実行の秒数であり、C++ の実行時間はゼロでした)、これは言及する価値があります。些細な...
編集 2011-06-10: C++ では、型の操作はコンパイル時に行われます。つまり、非ジェネリック コードを呼び出すジェネリック コードを生成します (たとえば、文字列から型 T へのジェネリック パーサー、認識した型 T の標準ライブラリ API を呼び出します。パーサーをユーザーが簡単に拡張できるようにすること) は非常に簡単で非常に効率的ですが、Java や C# で同等のものを記述するのはせいぜい面倒であり、コンパイル時に型がわかっている場合でも常に遅くなり、実行時に解決されます。あなたの唯一の希望は、JITがすべてをインライン化することです。
...
編集 2011-09-20: Blitz++ の背後にあるチーム (ホームページ、ウィキペディア) はその方向に進みました。明らかに、彼らの目標は、C++ テンプレート メタプログラミングを介して、ランタイム実行からコンパイル時間まで可能な限り移動することにより、科学計算で FORTRAN のパフォーマンスに到達することです。 . したがって、私が上に書いた「これに対する実際の影響はまだ見ていない」という部分は、明らかに実際に存在します。
C++ には Java/C# とは異なるメモリ使用量があるため、さまざまな利点/欠点があります。
JIT の最適化に関係なく、メモリーへの直接ポインター・アクセスほど高速なものはありません (プロセッサー・キャッシュなどはしばらく無視しましょう)。したがって、メモリ内に連続したデータがある場合、C++ ポインター (つまり、C ポインター... Caesar にその理由を説明しましょう) を介してアクセスすると、Java/C# よりも数倍速くなります。また、C++ には RAII があり、C# や Java よりも多くの処理がはるかに簡単になります。usingC++ は、そのオブジェクトの存在をスコープする必要はありません。finallyまた、C++ には節がありません。これはエラーではありません。
:-)
また、C# のプリミティブに似た構造体にもかかわらず、C++ の「スタック上の」オブジェクトは、割り当てと破棄にコストがかからず、クリーニングを行うために独立したスレッドで動作する GC を必要としません。
メモリの断片化に関しては、2008 年のメモリ アロケータは、通常 GC と比較される 1980 年の古いメモリ アロケータではありません。断片化が起こらないときの最適化？適切なタスクに適切なアロケーターを使用することは、C++ 開発者ツールキットの一部である必要があります。さて、アロケーターを書くのは簡単ではありません。そして、私たちのほとんどはもっとやるべきことがあります。ほとんどの場合、RAII または GC で十分です。
編集 2011-10-04:効率的なアロケーターの例: Windows プラットフォームでは、Vista 以降、低断片化ヒープがデフォルトで有効になっています。以前のバージョンでは、WinAPI 関数HeapSetInformationを呼び出すことで LFH をアクティブ化できます)。他の OS では、代替のアロケータが提供されています (https://secure.wikimedia.org/wikipedia/en/wiki/Mallocリスト)
現在、メモリ モデルは、マルチコアおよびマルチスレッド テクノロジの台頭により、やや複雑になっています。この分野では、.NET が優位に立っていると思います。Java が優位に立っているとのことでした。「ベア メタル上」のハッカーが、自分の「マシンに近い」コードを称賛するのは簡単です。しかし今では、コンパイラーに仕事を任せるよりも、手作業でより良いアセンブリーを作成する方がはるかに困難です。C++ の場合、コンパイラは通常、10 年間でハッカーよりも優れています。C# と Java の場合、これはさらに簡単です。
それでも、新しい標準 C++0x は C++ コンパイラに単純なメモリ モデルを課します。これにより、C++ の効果的なマルチプロセッシング/並列/スレッド コードが標準化され (したがって簡素化され)、コンパイラにとって最適化がより簡単かつ安全になります。しかし、その約束が守られるかどうかは、数年後にわかります。
注: このセクションでは、ネイティブ C++ ではなく、.NET によってホストされる C++ である C++/CLI について説明します。
先週、.NET の最適化に関するトレーニングを受けましたが、とにかく静的コンパイラが非常に重要であることを発見しました。JITと同じくらい重要です。
C++/CLI (またはその祖先である Managed C++) でコンパイルされたまったく同じコードは、C# (またはコンパイラが C# と同じ IL を生成する VB.NET) で生成された同じコードよりも数倍高速になる可能性があります。
C++ 静的コンパイラは、C# よりも最適化済みのコードを生成するのにはるかに優れていたためです。
たとえば、.NET での関数のインライン化は、バイトコードの長さが 32 バイト以下の関数に限定されます。そのため、C# の一部のコードは 40 バイトのアクセサーを生成しますが、これは JIT によってインライン化されることはありません。C++/CLI の同じコードは、JIT によってインライン化される 20 バイトのアクセサーを生成します。
もう 1 つの例は一時変数です。一時変数は、C# コンパイラによって生成された IL で引き続き言及されている一方で、C++ コンパイラによって単純にコンパイルされます。C++ 静的コンパイルの最適化により、コードが少なくなるため、より積極的な JIT 最適化が再度承認されます。
この理由は、C++/CLI コンパイラが C++ ネイティブ コンパイラの膨大な最適化技術から利益を得ているという事実であると推測されました。
私はC++が大好きです。
しかし、私が見る限り、C# または Java のほうが全体的に優れています。C++ よりも高速だからではなく、それらの品質を合計すると、C++ よりも生産性が向上し、必要なトレーニングが少なくなり、標準ライブラリがより完全になるためです。そして、ほとんどのプログラムに関しては、それらの速度の違いは (何らかの形で) ごくわずかです...
私は現在、ほぼ独占的なプロの C# コーディングを 5 か月間行っています (私の履歴書は、すでに C++ と Java でいっぱいで、C++/CLI のタッチも少しあります)。
私は WinForms (エヘム...) と WCF (クール!)、WPF (クール!!!! XAML と生の C# の両方を使用します。WPF はとても簡単で、Swing は比較できないと思います)、および C# 4.0 で遊んでいました。
結論は、C++ よりも C#/Java で動作するコードを生成する方が簡単で高速ですが、C# で強力で安全で堅牢なコードを生成するのは C++ よりもはるかに難しい (Java ではさらに難しい) ということです。理由はたくさんありますが、次のように要約できます。
using正しいDispose実装を書くのは難しいため、C＃でさえ簡単で強力ではありません）readonlyと Javafinalは、C++ ほど有用ではありませんconst( C# で読み取り専用の複雑なデータ (たとえば、ノードのツリー) を公開するには、C++ の組み込み機能ですが、膨大な作業が必要です。不変データは興味深いソリューションです)。 、しかし、すべてを不変にできるわけではないので、それだけでは十分ではありません)。したがって、C# は、機能するものが必要な限り快適な言語であり続けますが、常に安全に機能するものが必要な場合はイライラする言語です。
Java は C# と同じ問題を抱えているため、さらにイライラさせられます。C# のusingキーワードに相当するものがないため、私の非常に熟練した同僚は、リソースが正しく解放されていることを確認するのに多くの時間を費やしました。簡単でした（デストラクタとスマートポインタを使用）。
したがって、C#/Java による生産性の向上は、ほとんどのコードで目に見えるものだと思います...コードを可能な限り完璧にする必要がある日まで。その日、あなたは痛みを知るでしょう。(私たちのサーバーや GUI アプリから何を求められているのか信じられないでしょう...)。
建物の反対側にいるサーバー チーム (GUI チームに戻る前に 2 年間働きました) と連絡を取り合い、興味深いことを学びました。
Java には多くのフレームワーク/ツールがあり、保守やデプロイなどが容易であるため、Java サーバー アプリが古い C++ サーバー アプリに置き換わる運命にあります。
...ここ数か月、低レイテンシの問題が頭をよぎるまでは。次に、Java サーバー アプリは、熟練した Java チームが最適化を試みたにもかかわらず、実際には最適化されていない古い C++ サーバーとの競争に単純かつ明確に負けました。
現時点では、Java サーバーを一般的な使用のために維持することが決定されていますが、パフォーマンスは依然として重要であり、低レイテンシーのターゲットには関係なく、低レイテンシーおよび超低レイテンシーのニーズに合わせて既に高速な C++ サーバー アプリケーションを積極的に最適化しています。
期待ほど単純なものはありません。
Java、さらには C# は優れた言語であり、豊富な標準ライブラリとフレームワークを備えているため、すばやくコーディングしてすぐに結果を出すことができます。
しかし、生の力、強力で体系的な最適化、強力なコンパイラ サポート、強力な言語機能、および絶対的な安全性が必要な場合、Java と C# では、競合他社よりも優れた状態を維持するために必要な最後の欠落している重要な品質パーセントを獲得することは困難です。
平均的な品質のコードを生成するには、C++ よりも C#/Java の方が時間と経験の少ない開発者が必要であったかのようですが、一方で、優れた品質から完全な品質のコードが必要になった瞬間に、結果を得るのが突然簡単かつ迅速になりました。 C++で。
もちろん、これは私自身の認識であり、おそらく私たちの特定のニーズに限定されています.
しかし、それでも、GUI チームとサーバー側チームの両方で、今日起こっていることです。
もちろん、何か新しいことが起こったら、この投稿を更新します。
「パフォーマンスに関しては、C++ が大差をつけて勝っていることがわかりました。ただし、最も広範なチューニング作業も必要でした。その多くは、平均的なプログラマーが利用できない洗練されたレベルで行われました。
[...] Java バージョンはおそらく実装が最も簡単でしたが、パフォーマンスの分析が最も困難でした。特に、ガベージ コレクションに関する効果は複雑で、調整が非常に困難でした。」
ソース:
「Facebook では、『合理的に書かれた C++ コードは高速に実行される』というのが通説であり、PHP と Java コードの最適化に多大な労力が費やされていることを強調しています。逆説的に、C++ コードは他の言語よりも書くのが難しいですが、効率的なコードは[他の言語よりも C++ で書くほうが] はるかに簡単です。」
ソース:
一般に、C# と Java は、JIT コンパイラ (最初の実行時に IL をコンパイルするコンパイラ) が、C++ でコンパイルされたプログラムでは実行できない最適化を行うことができるため、C# と Java は同じかそれ以上の速度になります。マシンが Intel か AMD かを判断できます。Pentium 4、Core Solo、または Core Duo; またはSSE4などをサポートしている場合。
C++ プログラムは、すべてのマシンで問題なく動作するように、通常は混合最適化を使用して事前にコンパイルする必要がありますが、単一の構成 (つまり、プロセッサ、命令セット、その他のハードウェア) に対して最適化されるほどには最適化されていません。
さらに、特定の言語機能により、C# および Java のコンパイラーは、C/C++ コンパイラーにとって安全ではない特定の部分を最適化して取り除くことを可能にする、コードに関する仮定を行うことができます。ポインターにアクセスできる場合、安全ではない多くの最適化があります。
また、Java と C# は C++ よりも効率的にヒープ割り当てを行うことができます。これは、ガベージ コレクターとコードの間の抽象化レイヤーにより、すべてのヒープ圧縮を一度に実行できるためです (かなりコストのかかる操作)。
この次の点で Java について話すことはできませんが、たとえば C# は、メソッドの本体が空であることを認識している場合、メソッドとメソッド呼び出しを実際に削除することを知っています。そして、コード全体でこの種のロジックを使用します。
ご覧のとおり、特定の C# または Java の実装が高速になる理由はたくさんあります。
以上のことから、特定の最適化を C++ で行うことができます。これにより、C# で実行できることはすべて、特にグラフィック領域で、ハードウェアに近い場合はいつでも吹き飛ばされます。ここでポインターが驚くべき効果を発揮します。
だからあなたが書いているものに応じて、私はどちらか一方を使います. ただし、ハードウェアに依存しないもの (ドライバー、ビデオ ゲームなど) を作成している場合は、C# のパフォーマンスについて心配する必要はありません (ここでも Java について話すことはできません)。それはうまくいくでしょう。
Java 側の 1 つである@Swatiは、良い記事を指摘しています。
管理されたパフォーマンスと管理されていないパフォーマンスについて話すときはいつでも、Rico (および Raymond) が中国語/英語辞書の C++ バージョンと C# バージョンを比較したシリーズを参照するのが好きです。このグーグル検索で自分で読むことができますが、私はリコの要約が好きです.
だから私は私の大敗を恥じていますか？しそうにない。マネージ コードは、ほとんど労力をかけずに非常に良い結果を得ました。管理されたレイモンドを倒すには、次のことを行う必要がありました。
- 自分のファイル I/O を書く
- 独自の文字列クラスを作成する
- 自分のアロケーターを書く
- 独自の国際地図を作成
もちろん、彼はこれを行うために利用可能な下位レベルのライブラリを使用しましたが、それでもまだ多くの作業が必要です。残ったものを STL プログラムと呼べますか? 私はそうは思わない.彼はstd::vectorクラスを保持していたと思う. 他のほとんどすべてがなくなりました。
だから、うん、あなたは間違いなくCLRを打ち負かすことができます. Raymond は彼のプログラムをさらに高速化できると思います。
興味深いことに、両方のプログラムの内部タイマーによって報告されるファイルの解析時間はほぼ同じで、それぞれ 30 ミリ秒です。違いはオーバーヘッドにあります。
要するに、アンマネージド バージョンが元のアンマネージド コードの単純なポートであるマネージド バージョンを打ち負かすのに 6 回のリビジョンが必要だったということです。パフォーマンスの最後のすべてが必要な場合 (そしてそれを取得するための時間と専門知識がある場合) は、管理されていない状態にする必要がありますが、私にとっては、33 を超える最初のバージョンで得られた桁違いの利点を利用します。 % 6 回挑戦すると獲得できます。
特定の CPU 最適化のためのコンパイルは、通常過大評価されています。C++ でプログラムを作成し、pentium PRO 用に最適化してコンパイルし、pentium 4 で実行します。次に、pentium 4 用に最適化して再コンパイルします。いくつかのプログラムで長い午後を過ごしました。一般的な結果?? 通常、パフォーマンスの向上は 2 ～ 3% 未満です。したがって、理論的な JIT の利点はほとんどありません。パフォーマンスのほとんどの違いは、スカラー データ処理機能を使用している場合にのみ観察できます。最終的には、最大のパフォーマンスを達成するために手動で微調整する必要があります。この種の最適化は、実行に時間がかかり、コストがかかるため、とにかく JIT には適さない場合があります。
実世界と実際のアプリケーションでは、C++ は通常 Java よりも高速ですが、これは主にメモリ フットプリントが小さく、キャッシュ パフォーマンスが向上するためです。
しかし、C++ の機能をすべて使用するには、開発者は懸命に働かなければなりません。優れた結果を達成することはできますが、そのためには頭脳を使わなければなりません。C++ は、より多くのツールを提供することを決定した言語であり、言語をうまく使用できるようにするためにそれらを学ばなければならないという代償を払っています。
JIT (ジャスト イン タイム コンパイル) は、ターゲット プラットフォーム向けに最適化されるため、信じられないほど高速になります。
これは、開発者がコードを書いた CPU に関係なく、CPU がサポートできるあらゆるコンパイラ トリックを利用できることを意味します。
.NET JIT の基本概念は次のように機能します (大幅に簡略化されています)。
初めてメソッドを呼び出す:
2 回目のメソッド呼び出し:
ご覧のとおり、2 回目は、リアルタイム最適化の利点を除けば、C++ と実質的に同じプロセスです。
そうは言っても、マネージ言語の速度を低下させるオーバーヘッドの問題は他にもありますが、JIT は大いに役立ちます。
私はOrion Adrianの答えが好きですが、それには別の側面があります。
アセンブリ言語と FORTRAN のような「人間の」言語について、同じ質問が何十年も前に提起されました。そして、答えの一部は似ています。
はい、C++ プログラムは、特定の (自明ではない?) アルゴリズムで C# よりも高速にすることができますが、C# のプログラムは、多くの場合、C++ の「素朴な」実装や C++ の最適化されたバージョンと同じか、それよりも高速です。開発には時間がかかりますが、それでも C# バージョンよりもわずかな差で勝っている可能性があります。それで、それは本当に価値がありますか？
その質問に 1 つずつ答える必要があります。
そうは言っても、私は C++ の長年のファンであり、信じられないほど表現力豊かで強力な言語だと思いますが、過小評価されることもあります。しかし、多くの「実生活」の問題 (個人的には、それは「解決するために報酬を得る種類」を意味します) では、C# の方がより迅速かつ安全に仕事を完了できます。
あなたが支払う最大のペナルティは？多くの .NET および Java プログラムはメモリを大量に消費します。私は、.NET および Java アプリが「数百メガバイト」のメモリを消費するのを見てきましたが、同様の複雑さの C++ プログラムは、「数十」メガバイトをかろうじてスクラッチします。
Hotspot を使用した場合でも、Java コードが C++ よりも高速に実行されることがどれくらいの頻度で発生するかはわかりませんが、それがどのように発生するかを簡単に説明します。
コンパイルされた Java コードは、JVM の解釈された機械語と考えてください。Hotspot プロセッサは、コンパイルされたコードの特定の部分が何度も使用されることを認識すると、マシン コードの最適化を実行します。手動でアセンブリをチューニングすると、ほとんどの場合、C++ でコンパイルされたコードよりも高速になるため、プログラムでチューニングされたマシン コードがそれほど悪くないと考えても問題ありません。
したがって、非常に反復的なコードの場合、Hotspot JVM が C++ よりも高速に Java を実行できる場所を確認できました...ガベージ コレクションが機能するまでは。:)
一般に、プログラムのアルゴリズムは、言語よりもアプリケーションの速度にとってはるかに重要です。C++ を含む任意の言語で貧弱なアルゴリズムを実装できます。それを念頭に置いて、より効率的なアルゴリズムを実装するのに役立つ言語で、より高速に実行されるコードを書くことができます。
高水準言語は、多くの効率的な事前構築済みデータ構造へのアクセスを容易にし、非効率的なコードを回避するのに役立つ慣行を奨励することで、この点で非常にうまく機能します。もちろん、非常に遅いコードの束を簡単に記述できる場合もあるため、プラットフォームを理解する必要があります。
また、C++ は、STL コンテナー、自動ポインターなどの「新しい」(引用符に注意してください) 機能に追いついています。たとえば、boost ライブラリを参照してください。また、あるタスクを達成するための最速の方法には、高水準言語では禁止されているポインター演算のような手法が必要であることに気付く場合もありますが、これらの手法を使用すると、必要に応じて実装できる言語で記述されたライブラリを呼び出すことができます。 .
主なことは、使用している言語、関連する API、できること、制限事項を知ることです。
私もわかりません...私のJavaプログラムはいつも遅いです。:-) ただし、C# プログラムが特に遅いことに気づいたことはありません。
「より良いパフォーマンス」を定義する必要があります。ええと、私は知っています、あなたは速度について尋ねました、しかしそれは重要なすべてではありません。
など、その偏り、はい;）
C＃とJavaを使用すると、得られるもの（より高速なコーディング、自動メモリ管理、大きなライブラリなど）に対して代償を払うことになります。しかし、あなたは詳細について口論する余地があまりありません：完全なパッケージをとるか、何も取らないでください。
それらの言語がコンパイルされたコードよりも速く実行するように一部のコードを最適化できるとしても、全体のアプローチは（IMHO）非効率的です。トラックを使って、職場まで5マイル毎日運転することを想像してみてください。その快適さ、それは心地よい、あなたは安全であり（極端なクラッシャブルゾーン）、そしてあなたがしばらくの間ガスを踏んだ後、それは標準的な車と同じくらい速くなるでしょう！なぜ私たち全員が仕事のために運転するトラックを持っていないのですか？;）
C ++では、あなたはあなたが支払うものを手に入れますが、それ以上でもそれ以下でもありません。
Bjarne Stroustrupの引用：「C ++はガベージをほとんど生成しないため、私のお気に入りのガベージコレクション言語です」 リンクテキスト
これは、自分のコンピューターで試すことができるもう1つの興味深いベンチマークです。
ASM、VC ++、C＃、Silverlight、Javaアプレット、Javascript、Flash（AS3）を比較します
javascriptの速度は、実行しているブラウザによって大きく異なることに注意してください。これらのプラグインはホスティングブラウザと同じプロセスで実行されるため、FlashとSilverlightについても同じことが言えます。ただし、Roozzプラグインは独自のプロセスで実行される標準の.exeファイルを実行するため、速度はホスティングブラウザの影響を受けません。
最も重要なJIT最適化の1つは、メソッドのインライン化です。Javaは、実行時の正確性を保証できる場合、仮想メソッドをインライン化することもできます。この種の最適化は、プログラム全体の分析が必要なため、通常、標準の静的コンパイラでは実行できません。これは、個別のコンパイルのために困難です（対照的に、JITではすべてのプログラムを使用できます）。メソッドのインライン化は他の最適化を改善し、最適化するためのより大きなコードブロックを提供します。
Java / C＃での標準のメモリ割り当ても高速であり、割り当て解除（GC）はそれほど遅くはありませんが、決定論的ではありません。
C++ を学習している Java/C# プログラマーは、Java/C# の観点から考え続け、逐語的に C++ 構文に変換したくなるでしょう。その場合、前述のネイティブ コードとインタープリター/JIT の利点のみが得られます。C++ と Java/C# の比較で最大のパフォーマンス向上を得るには、C++ で考え、特に C++ の長所を活用するようにコードを設計することを学ぶ必要があります。
Edsger Dijkstraを言い換えると、[あなたの第一言語] 回復を超えて心を傷つけます。ジェフ・アトウッド
の
言葉を言い換えると、[あなたの母国語] はどんな新しい言語でも書くことができます。
Orion Adrianさん、C++ についても多くのことが言えるので、投稿を反転させて、あなたの発言がどれほど根拠のないものかを確認させてください。そして、Java/C# コンパイラが空の関数を最適化して取り除くと言うと、あなたは最適化の専門家ではないように聞こえます。なぜなら、a) 本当に悪いレガシー コードを除いて、なぜ実際のプログラムに空の関数を含めるべきなのか、b) 実際にはそうではないからです。黒と出血エッジの最適化。
そのフレーズとは別に、ポインタについて露骨に暴言を吐きましたが、Java や C# のオブジェクトは基本的に C++ のポインタのように機能するのではないですか? それらは重ならないでしょうか？それらはnullにならないでしょうか？C (およびほとんどの C++ 実装) には restrict キーワードがあり、両方に値の型があり、C++ には非 null 保証の値への参照があります。Java と C# は何を提供しますか?
一般に、C と C++ は、AOT コンパイラ (ハイ メモリのメニー コア ビルド サーバー上で展開前に一度だけコードをコンパイルするコンパイラ) が、C# でコンパイルされたプログラムを最適化できるため、C と C++ は同等またはそれ以上の速さである可能性があります。そうするための時間がたくさんあるのでできません。コンパイラは、マシンが Intel か AMD かを判別できます。Pentium 4、Core Solo、または Core Duo; または、SSE4 などをサポートしている場合で、コンパイラがランタイム ディスパッチをサポートしていない場合は、少数の特殊なバイナリを展開することで自分で解決できます。
AC# プログラムは通常、実行時にコンパイルされるため、すべてのマシンで問題なく動作しますが、単一の構成 (つまり、プロセッサ、命令セット、その他のハードウェア) に対して可能な限り最適化されておらず、ある程度の時間を費やす必要があります。最初。ループ分割、ループ反転、自動ベクトル化、プログラム全体の最適化、テンプレート展開、IPO などの機能は、エンド ユーザーを悩ませない方法ですべて完全に解決するのは非常に困難です。
さらに、特定の言語機能により、C++ または C のコンパイラーは、Java/C# コンパイラーにとって安全ではない特定の部分を最適化して取り除くことを可能にする、コードに関する仮定を行うことができます。ジェネリックの完全な型 ID または保証されたプログラム フローにアクセスできない場合、安全ではない多くの最適化が行われます。
また、C++ と C は、1 回のレジスタ インクリメントで一度に多くのスタック割り当てを行います。ガベージ コレクターとコードの間の抽象化レイヤーに関しては、Java や C# の割り当てよりも確実に効率的です。
この次の点についてJavaについて話すことはできませんが、たとえばC++コンパイラは、メソッドの本体が空であることを認識している場合、メソッドとメソッド呼び出しを実際に削除し、一般的な部分式を削除し、試行して再試行する可能性があることを知っています最適なレジスタの使用法を見つけるために、境界チェックを強制せず、ループと内側のループを自動ベクトル化し、内側から外側に反転し、条件をループから移動し、ループを分割および非分割します。C の方法で行うように、std::vector をネイティブのゼロ オーバーヘッド配列に展開します。手続き間の最適化を行います。呼び出し元サイトで直接戻り値を構築します。式を折りたたんで伝播します。キャッシュに適した方法でデータを並べ替えます。ジャンプスレッドを実行します。これにより、ランタイム オーバーヘッドなしでコンパイル時のレイ トレーサーを作成できます。非常に高価なグラフベースの最適化を行います。特定のコードを構文的に完全に等しくないが意味的には同等のコードに置き換えると、強度が低下します（古い「xor foo、foo」は、そのような種類の時代遅れの最適化ではありますが、最も単純です）。親切にお願いすれば、IEEE 浮動小数点標準を省略して、浮動小数点オペランドの並べ替えなどのさらに多くの最適化を有効にすることができます。コードをマッサージして大虐殺した後、プロセス全体を繰り返す可能性があります。これは、特定の最適化がさらに特定の最適化の基盤となることがよくあるためです。また、パラメータをシャッフルして再試行し、内部ランキングで他のバリアントのスコアを確認することもできます。そして、コード全体でこの種のロジックを使用します。特定のコードを、構文的には完全に等しくないが意味的には同等のコードに置き換えます（古い「xor foo、foo」は、そのような種類の時代遅れの最適化ではありますが、最も単純です）。親切にお願いすれば、IEEE 浮動小数点標準を省略して、浮動小数点オペランドの並べ替えなどのさらに多くの最適化を有効にすることができます。コードをマッサージして大虐殺した後、プロセス全体を繰り返す可能性があります。これは、特定の最適化がさらに特定の最適化の基盤となることがよくあるためです。また、パラメータをシャッフルして再試行し、内部ランキングで他のバリアントのスコアを確認することもできます。そして、コード全体でこの種のロジックを使用します。特定のコードを、構文的には完全に等しくないが意味的には同等のコードに置き換えます（古い「xor foo、foo」は、そのような種類の時代遅れの最適化ではありますが、最も単純です）。親切にお願いすれば、IEEE 浮動小数点標準を省略して、浮動小数点オペランドの並べ替えなどのさらに多くの最適化を有効にすることができます。コードをマッサージして大虐殺した後、プロセス全体を繰り返す可能性があります。これは、特定の最適化がさらに特定の最適化の基盤となることがよくあるためです。また、パラメータをシャッフルして再試行し、内部ランキングで他のバリアントのスコアを確認することもできます。そして、コード全体でこの種のロジックを使用します。親切にお願いすれば、IEEE 浮動小数点標準を省略して、浮動小数点オペランドの並べ替えなどのさらに多くの最適化を有効にすることができます。コードをマッサージして大虐殺した後、プロセス全体を繰り返す可能性があります。これは、特定の最適化がさらに特定の最適化の基盤となることがよくあるためです。また、パラメータをシャッフルして再試行し、内部ランキングで他のバリアントのスコアを確認することもできます。そして、コード全体でこの種のロジックを使用します。親切にお願いすれば、IEEE 浮動小数点標準を省略して、浮動小数点オペランドの並べ替えなどのさらに多くの最適化を有効にすることができます。コードをマッサージして大虐殺した後、プロセス全体を繰り返す可能性があります。これは、特定の最適化がさらに特定の最適化の基盤となることがよくあるためです。また、パラメータをシャッフルして再試行し、内部ランキングで他のバリアントのスコアを確認することもできます。そして、コード全体でこの種のロジックを使用します。また、パラメータをシャッフルして再試行し、内部ランキングで他のバリアントのスコアを確認することもできます。そして、コード全体でこの種のロジックを使用します。また、パラメータをシャッフルして再試行し、内部ランキングで他のバリアントのスコアを確認することもできます。そして、コード全体でこの種のロジックを使用します。
ご覧のとおり、特定の C++ または C の実装が高速になる理由はたくさんあります。
以上のことから、多くの最適化を C++ で行うことができ、C# で実行できることをすべて吹き飛ばすことができます。特に、数値処理、リアルタイム、および金属に近い領域では、それだけではありません。長い道のりを歩むために、単一のポインターに触れる必要さえありません。
だからあなたが書いているものに応じて、私はどちらか一方を使います。ただし、ハードウェアに依存しないもの (ドライバー、ビデオ ゲームなど) を作成している場合は、C# のパフォーマンスについて心配する必要はありません (ここでも Java について話すことはできません)。それはうまくいくでしょう。
一般的に、特定の一般化された議論は、特定の投稿ではクールに聞こえるかもしれませんが、一般的に確実に信頼できるとは言えません。
とにかく、平和を作るために: AOTはJITと同様に素晴らしいです。唯一の正しい答えは次のとおりです。そして、真に頭の良い人は、とにかく両方の長所を活かすことができることを知っています。
あなたが尋ねた特定の質問について、ここにいくつかの良い答えがあります。一歩下がって全体像を見たいと思います。
作成したソフトウェアの速度に対するユーザーの認識は、codegen の最適化の程度だけでなく、他の多くの要因の影響を受けることに注意してください。ここではいくつかの例を示します。
手動のメモリ管理は、正しく (リークなしで) 行うのが難しく、効率的に行うのはさらに困難です (作業が終わったらすぐにメモリを解放します)。一般に、GC を使用すると、メモリを適切に管理するプログラムが生成される可能性が高くなります。GC を凌駕しようとして、一生懸命働き、ソフトウェアの提供を遅らせても構わないと思っていますか?
私の C# は、私の C++ よりも読みやすく理解しやすいです。また、自分の C# コードが正しく機能していることを確信する方法は他にもあります。つまり、バグを導入するリスクを抑えてアルゴリズムを最適化できるということです (また、ユーザーは、たとえクラッシュが速くても、ソフトウェアがクラッシュするのを好みません!)
C++ よりも C# の方が速くソフトウェアを作成できます。これにより、パフォーマンスに取り組む時間が解放され、ソフトウェアを予定どおりに提供できます。
C++ よりも C# で優れた UI を作成する方が簡単なので、UI の応答性を維持しながら作業をバックグラウンドにプッシュしたり、プログラムがしばらくブロックする必要があるときに進行状況やハートビート UI を提供したりできる可能性が高くなります。これによって何も速くなるわけではありませんが、ユーザーは待つことに満足しています。
私が C# について述べたことはすべておそらく Java にも当てはまりますが、確実に言える経験がありません。
Java または C# コンパイラから生成された実行可能コードは解釈されません。「ジャスト イン タイム」(JIT) でネイティブ コードにコンパイルされます。そのため、Java/C# プログラムのコードが実行中に初めて検出されると、"ランタイム コンパイラ" (別名 JIT コンパイラ) がバイト コード (Java) または IL コード (C#) をネイティブ マシン命令に変換するため、いくらかのオーバーヘッドが発生します。ただし、アプリケーションの実行中に次にそのコードが検出されると、ネイティブ コードがすぐに実行されます。これは、一部の Java/C# プログラムが最初は遅く見えるが、実行時間が長くなるほどパフォーマンスが向上することを説明しています。良い例は、ASP.Net Web サイトです。Web サイトに初めてアクセスするときは、C# コードが JIT コンパイラによってネイティブ コードにコンパイルされるため、少し遅くなる場合があります。
仮想マシン言語がコンパイル済み言語より優れている可能性は低いですが、(少なくとも) 次の理由により、問題にならないほど十分に近くなる可能性があります (私は C# をやったことがないので、ここでは Java について話しています)。
1/ Java ランタイム環境は、通常、頻繁に実行されるコードの断片を検出し、それらのセクションの Just-In-Time (JIT) コンパイルを実行して、将来的に完全なコンパイル速度で実行できるようにします。
2/ Java ライブラリの大部分はコンパイルされているため、ライブラリ関数を呼び出すと、コンパイルされたコードが実行され、解釈されません。OpenJDK をダウンロードすると、コード (C) を確認できます。
3/ 大規模な計算を行っていない限り、プログラムが実行されているほとんどの時間は、非常に遅い (比較的言えば) 人間からの入力を待っています。
4/ クラスのロード時に Java バイトコードの多くの検証が行われるため、実行時チェックの通常のオーバーヘッドが大幅に削減されます。
5/ 最悪の場合、パフォーマンスを重視するコードをコンパイル済みモジュールに抽出し、Java (JNI を参照) から呼び出して、フルスピードで実行することができます。
要約すると、Java バイトコードがネイティブの機械語を上回ることはありませんが、これを軽減する方法があります。Java の大きな利点 (私が見ているように) は、巨大な標準ライブラリとクロスプラットフォームの性質です。
実際、C# は Java のように仮想マシンで実行されるわけではありません。IL は、完全にネイティブ コードであるアセンブリ言語にコンパイルされ、ネイティブ コードと同じ速度で実行されます。.NET アプリケーションを pre-JIT することで、JIT コストを完全になくすことができ、完全にネイティブ コードを実行できます。
.NET の速度低下は、.NET コードが遅いためではなく、ガベージ コレクション、参照のチェック、完全なスタック フレームの保存などを行うために舞台裏で多くのことを行うためです。アプリケーションを構築できますが、コストもかかります。これらすべてを C++ プログラムでも実行できることに注意してください (コア .NET 機能の多くは、実際には ROTOR で表示できる .NET コードです)。ただし、同じ機能を手動で記述した場合、.NET ランタイムが最適化および微調整されているため、プログラムの実行速度が大幅に低下する可能性があります。
つまり、マネージド コードの強みの 1 つは、完全に検証できることです。コードを実行する前に、コードが別のプロセスのメモリにアクセスしたり、不適切なことを行ったりしないことを確認できます。Microsoft は、完全に管理されたオペレーティング システムの研究用プロトタイプを持っています。驚くべきことに、100% 管理された環境は、この検証を利用して、管理されたプログラムで不要になったセキュリティ機能をオフにすることで、最新のオペレーティング システムよりも大幅に高速に実行できることを示しています。 (場合によっては 10 倍のように話しています)。SEラジオは、このプロジェクトについて語る素晴らしいエピソードを持っています.
これは、Java インタープリターが生成するマシン コードが、コンパイラーが記述している C++ コード用に生成するマシン コードよりも実際に最適化されている場合にのみ発生し、C++ コードが Java よりも遅くなり、解釈コストがかかる点にまで達します。
ただし、それが実際に起こる可能性は非常に低いです。おそらく、Java のライブラリが非常に適切に作成されていて、独自の C++ ライブラリが適切に作成されていない場合を除きます。
私の理解では、C / C ++は、特定のマシンアーキテクチャで実行するネイティブコードを生成します。逆に、JavaやC＃のような言語は、ネイティブアーキテクチャを抽象化する仮想マシン上で実行されます。論理的には、この中間ステップのためにJavaまたはC＃がC ++の速度に匹敵することは不可能に思えますが、最新のコンパイラ（「ホットスポット」）はこの速度を達成できるか、それを超えることさえできると言われています。
それは非論理的です。中間表現を使用しても、本質的にパフォーマンスが低下することはありません。たとえば、llvm-gccは、LLVM IR（仮想無限レジスタマシン）を介してCおよびC ++をネイティブコードにコンパイルし、優れたパフォーマンスを実現します（多くの場合、GCCを上回ります）。
おそらくこれは言語の質問というよりはコンパイラの質問ですが、これらの仮想マシン言語の1つが母国語よりも優れたパフォーマンスを発揮する方法を平易な英語で説明できる人はいますか？
ここではいくつかの例を示します。
JITコンパイルを備えた仮想マシンは、実行時コード生成（System.Reflection.Emit.NETなど）を容易にするため、生成されたコードをC＃やF＃などの言語でオンザフライでコンパイルできますが、CまたはC++で比較的低速のインタープリターを作成する必要があります。たとえば、正規表現を実装します。
CおよびC++は十分な速度のコードを生成しないため、仮想マシンの一部（書き込みバリアやアロケータなど）は、多くの場合、手動でコード化されたアセンブラーで記述されます。プログラムがシステムのこれらの部分にストレスをかける場合、CまたはC++で記述できるものよりもパフォーマンスが優れている可能性があります。
ネイティブコードの動的リンクには、パフォーマンスを妨げ、プログラム全体の最適化を不要にするABIへの準拠が必要ですが、リンクは通常VMで延期され、プログラム全体の最適化（.NETの改良されたジェネリックなど）の恩恵を受けることができます。
また、上記のpaercebalの非常に賛成の回答（誰かが彼の回答に対する私のコメントを削除し続けるため）に関するいくつかの問題に対処したいと思います。これは、逆効果的に二極化された見解を示します。
コード処理はコンパイル時に行われます...
したがって、テンプレートメタプログラミングは、プログラムがコンパイル時に利用可能である場合にのみ機能しますが、これは多くの場合そうではありません。たとえば、実行時のコード生成ができないため、バニラC ++で競争力のある正規表現ライブラリを作成することは不可能です（メタプログラミング）。
...型の操作はコンパイル時に行われます...JavaまたはC＃での同等のものは、書くのが苦痛であり、コンパイル時に型がわかっている場合でも、実行時に常に遅くなり、解決されます。
C＃では、これは参照型にのみ当てはまり、値型には当てはまりません。
JITの最適化に関係なく、メモリへの直接ポインタアクセスほど高速なものはありません...メモリ内に連続したデータがある場合、C ++ポインタ（つまり、Cポインタ... Caesarに期限を与えましょう）を介してデータにアクセスすると、何倍も速くなりますJava / C＃よりも。
ポインタがエイリアシング関連の最適化を妨げるため、SciMark2ベンチマークのSORテストでJavaがC++を上回っているのを人々は観察しています。
また、.NETはリンク後にダイナミックリンクライブラリ全体でジェネリックスの型の特殊化を行いますが、C ++はリンクする前にテンプレートを解決する必要があるため、できません。そして明らかに、ジェネリックスがテンプレートよりも優れている大きな利点は、わかりやすいエラーメッセージです。
実際、SunのHotSpot JVMは、「混合モード」実行を使用します。メソッドのバイトコードは、特定のコードブロック（メソッド、ループ、try-catchブロックなど）が大量に実行されると判断されるまで（通常は何らかのカウンターを介して）解釈され、JITでコンパイルされます。メソッドをJITコンパイルするのに必要な時間は、ほとんど実行されないメソッドである場合、メソッドが解釈される場合よりも長くかかることがよくあります。通常、「混合モード」の方がパフォーマンスが高くなります。これは、JVMが、実行されることはめったにないJITコードの時間を無駄にしないためです。C＃と.NETはこれを行いません。.NET JITは、多くの場合、時間を浪費するすべてのものをJITします。
Java または CLR が C++ よりも高速な場合、短いバーストが発生する可能性がありますが、全体的なパフォーマンスは、アプリケーションの存続期間中は悪化します。その結果については、www.codeproject.com/KB/dotnet/RuntimePerformance.aspx を参照してください。
HP Labs のDynamoについて読んでください。Dynamoは、PA-8000 上で動作する PA-8000 用のインタープリターであり、多くの場合、ネイティブよりも高速にプログラムを実行します。そうすれば、まったく驚くべきことではありません！
それを「中間ステップ」と考えないでください。プログラムの実行には、どの言語でも、すでに多くの他のステップが含まれています。
多くの場合、次のようになります。
プログラムにはホットスポットがあるため、実行する必要があるコード本体の 95% の実行が遅くても、ホット 5% で高速であれば、パフォーマンス競争力を維持できます。
HLL は C/C++ のような LLL よりもユーザーの意図をよく知っているため、より最適化されたコードを生成できます (OCaml にはさらに多くの機能があり、実際にはより高速なことがよくあります)。
JIT コンパイラーには、静的コンパイラーにはない多くの情報があります (たとえば、今回たまたま得た実際のデータなど)。
JIT コンパイラーは、従来のリンカーでは実際には許可されていない最適化を実行時に実行できます (一般的なケースがフラットになるように分岐を並べ替えたり、ライブラリ呼び出しをインライン化するなど)。
全体として、C/C++ はパフォーマンスの点でかなりお粗末な言語です。データ型に関する情報は比較的少なく、データに関する情報はなく、実行時の最適化を可能にする動的なランタイムもありません。
ここに興味深いベンチマークがあります http://zi.fi/shootout/
Cliff Click からの回答は次のとおりです。 http://www.azulsystems.com/blog/cliff/2009-09-06-java-vs-c-performanceagain
場合によっては、マネージ コードが実際にはネイティブ コードよりも高速になることがあります。たとえば、「マークアンドスイープ」ガベージ コレクション アルゴリズムを使用すると、JRE や CLR などの環境で、ほとんどの C/C++ ヒープ オブジェクトが 1 つずつ解放される、1 回のパスで大量の存続期間の短い (通常は) オブジェクトを解放できます。時間。
ウィキペディアから：
多くの実用的な目的のために、ガベージ コレクション言語で実装された割り当て/割り当て解除を多用するアルゴリズムは、手動ヒープ割り当てを使用する同等のアルゴリズムよりも実際には高速です。この主な理由は、ガベージ コレクターにより、ランタイム システムが潜在的に有利な方法で割り当ておよび割り当て解除操作を償却できるようになるためです。
そうは言っても、私は多くの C# と C++ を作成し、多くのベンチマークを実行してきました。私の経験では、C++ は次の 2 つの点で C# よりもはるかに高速です。(1) C# で記述したコードを C++ に移植すると、ネイティブ コードの方が高速になる傾向があります。どのくらい速くなりますか？かなりの差がありますが、速度が 100% 向上することも珍しくありません。(2) 場合によっては、ガベージ コレクションによってマネージド アプリケーションの速度が大幅に低下することがあります。.NET CLR は大きなヒープ (たとえば、2 GB を超える) でひどい仕事をし、最終的に GC で多くの時間を費やすことになる可能性があります。
もちろん、私が遭遇したほとんどの場合、マネージ言語は長い目で見れば十分に高速であり、C++ の追加のパフォーマンスに対するメンテナンスとコーディングのトレードオフは、単に良いものではありません。
多くの速度を必要とするものについては、JVMはC ++実装を呼び出すだけなので、ほとんどのOS関連のものに対してJVMがどれだけ優れているかよりも、ライブラリがどれだけ優れているかが問題になります。ガベージコレクションはメモリを半分に削減しますが、より洗練されたSTLおよびBoost機能のいくつかを使用すると同じ効果が得られますが、バグの可能性が何倍もあります。
多くのクラスを含む大規模なプロジェクトでC++ライブラリとその高レベルの機能の多くを使用している場合は、JVMを使用するよりも遅くなる可能性があります。エラーが発生しやすいことを除いて。
ただし、C ++の利点は、自分自身を最適化できることです。そうしないと、compiler/jvmの機能にとらわれてしまいます。独自のコンテナを作成し、調整された独自のメモリ管理を記述し、SIMDを使用して、あちこちでアセンブリにドロップすると、ほとんどのC++コンパイラが独自に実行する速度よりも少なくとも2倍から4倍高速化できます。一部の操作では、16x〜32x。これは同じアルゴリズムを使用しています。より優れたアルゴリズムを使用して並列化すると、劇的に増加する可能性があり、一般的に使用される方法よりも数千倍速くなることもあります。
いくつかの異なる点から見ていきます。
他の人が言ったことに加えて、私の理解では、.NET と Java はメモリ割り当てに優れています。たとえば、断片化されたメモリを圧縮できますが、C++ ではできません (ネイティブですが、巧妙なガベージ コレクターを使用している場合は可能です)。
非常に短い答え: 固定予算を考えると、C++ アプリケーションよりもパフォーマンスの高い Java アプリケーションを実現できます (ROI の考慮事項)。さらに、Java プラットフォームには適切なプロファイラーがあり、ホットスポットをより迅速に特定するのに役立ちます。