質問

それとも今では逆ですか?

聞いたことから、C#がC ++よりも高速であることが証明されている領域がいくつかありますが、自分でテストする勇気を持っていません。

これらの違いを詳細に説明したり、この情報の適切な場所を教えてくれると思います。

役に立ちましたか?

解決

C#やJITを備えたJavaなどのバイトコードベースの言語がC ++コードほど高速になれない厳密な理由はありません。ただし、C ++コードは長い間ずっと高速でしたが、今日でも多くの場合に使用されています。これは主に、実装が複雑なより高度なJIT最適化によるものであり、非常に優れたJIT最適化はたった今到着しているだけです。

したがって、多くの場合、C ++の方が高速です。しかし、これは答えの一部にすぎません。 C ++が実際に高速であるケースは、高度に最適化されたプログラムであり、熟練したプログラマーがコードの徹底的な最適化を行います。これは非常に時間のかかる(したがって高価な)だけでなく、一般に最適化の過剰によるエラーにつながります。

一方、インタプリタ言語のコードは、後のバージョンのランタイム(.NET CLRまたはJava VM)では、何もしなくても高速になります。また、JITコンパイラーが実行できる便利な最適化はたくさんありますが、それはポインターを使用する言語では不可能です。また、ガベージコレクションは通常、手動のメモリ管理と同じかそれよりも高速である必要があると主張する人もいますが、多くの場合はそうです。通常、これらのすべてをC ++またはCで実装および実現できますが、はるかに複雑でエラーが発生しやすくなります。

ドナルド・クヌースが言ったように、「時期尚早な最適化はすべての悪の根源です」。アプリケーションがほとんどの場合、パフォーマンスが非常に重要な算術演算で構成されており、それがボトルネックになり、C ++の方が確かに高速になり、C ++が他のアプリケーションと競合しないことが確実にわかっている場合要件は、C ++に進みます。それ以外の場合は、最初に最適な言語でアプリケーションを正しく実装し、実行が遅すぎる場合はパフォーマンスのボトルネックを見つけてから、コードを最適化する方法を検討してください。最悪の場合、外部関数インターフェイスを介してCコードを呼び出す必要があります。そのため、重要な部分を低レベルの言語で書くことができます。

正しいプログラムを最適化するのは比較的簡単ですが、最適化されたプログラムを修正するのははるかに難しいことに留意してください。

速度の利点の実際の割合を与えることは不可能であり、コードに大きく依存します。多くの場合、プログラミング言語の実装はボトルネックではありません。 http://benchmarksgame.alioth.debian.org/ のベンチマークを非常に懐疑的に取ります、これらは主に算術コードをテストするため、コードとまったく似ていない可能性が高いです。

他のヒント

C#は高速ではないかもしれませんが、YOU / MEは高速になります。それは私がやることにとって最も重要な尺度です。 :)

オレンジが5つ速くなりました。むしろ:(正しい)包括的な回答はあり得ません。 C ++は静的にコンパイルされた言語です(ただし、プロファイルガイドによる最適化もあります)。C#はJITコンパイラーによって実行されます。非常に多くの違いがあるので、「#8220;どのくらい高速ですか?」などの質問があります。大きさを与えても答えられません。

次のように述べて、この質問に対する受け入れられた(そしてよく支持された)回答の一部に反対することから始めます。

実際には、JITtedコードの実行が適切に最適化されたC ++(またはランタイムオーバーヘッドのない他の言語)よりも遅くなる理由はたくさんあります プログラムを含む:

    実行時にJITtingコードに費やされる
  • 計算サイクルは、プログラムの実行で使用することは定義上不可能です。

  • JITterのホットパスは、CPUの命令およびデータキャッシュのコードと競合します。パフォーマンスに関しては、キャッシュが支配的であり、C ++などのネイティブ言語には、このタイプの競合は定義されていません。

  • ランタイムオプティマイザーの時間バジェットは、(別のコメント作成者が指摘したように)コンパイル時オプティマイザーの時間バジェットよりも必然的にはるかに制約されます

一番下の行:最終的に、C#でできるよりもC ++での実装をほぼ確実に 作成できます。

とはいえ、タスク、問題の領域、ハードウェア、実装の品質、その他多くの要因が多すぎるため、どれほど高速なのかは実際には定量化できません。シナリオでテストを実行してパフォーマンスの違いを判断し、追加の労力と複雑さに見合う価値があるかどうかを判断します。

これは非常に長く複雑なトピックですが、完全を期すために、C#のランタイムオプティマイザーが優れており、コンパイル時にC ++で使用できない特定の動的最適化を実行時に実行できることを言及する価値があります-time(静的)オプティマイザー。この場合でも、通常はネイティブアプリケーションの裁判所に優位性がありますが、動的オプティマイザーが「 ほぼ 」の理由です。上記の修飾子。

-

相対的なパフォーマンスの観点から、私は他のいくつかの回答で見た数字や議論にも邪魔されたので、上に述べた声明を支持すると同時に、チャイムになると思った。

これらのベンチマークの問題の大部分は、C#を書いているかのようにC ++コードを記述できず、代表的な結果が得られることを期待できることです(たとえば、C ++で数千のメモリ割り当てを実行すると、ひどい数字が得られます)。 )

代わりに、私は少し慣用的なC ++コードを作成し、@ Wioryが提供するC#コードと比較しました。 C ++コードに加えた2つの主要な変更は次のとおりです。

1)vector :: reserve()を使用

2)キャッシュの局所性を向上させるために2d配列を1dに平坦化しました(連続ブロック)

C#(.NET 4.6.1)

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);
}

実行時間(リリース):Init:124ms、Fill:165ms

C ++ 14(Clang v3.8 / C2)

#include <iostream>
#include <vector>

auto TestSuite::ColMajorArray()
{
    constexpr size_t ROWS = 5000;
    constexpr size_t COLS = 9000;

    auto initStart = std::chrono::steady_clock::now();

    auto arr = std::vector<double>();
    arr.reserve(ROWS * COLS);

    auto initFinish = std::chrono::steady_clock::now();
    auto initTime = std::chrono::duration_cast<std::chrono::microseconds>(initFinish - initStart);

    auto fillStart = std::chrono::steady_clock::now();

    for(auto i = 0, r = 0; r < ROWS; ++r)
    {
        for (auto c = 0; c < COLS; ++c)
        {
            arr[i++] = static_cast<double>(r * c);
        }
    }

    auto fillFinish = std::chrono::steady_clock::now();
    auto fillTime = std::chrono::duration_cast<std::chrono::milliseconds>(fillFinish - fillStart);

    return std::make_pair(initTime, fillTime);
}

実行時間(リリース):Init:398&#181; s(はい、マイクロ秒)、Fill:152ms

合計実行時間:C#:289ms、C ++ 152ms(約90%高速)

観測

C ++が依然として優勢である(そして今後数年間)という特定のシナリオは、コンパイル時にポリモーフィックな決定を事前に決定できる場合に発生します。

一般に、カプセル化と据え置きの意思決定は、コードをより動的にし、変化する要件に容易に適合させ、フレームワークとして使用しやすくするため、良いことです。これが、C#でのオブジェクト指向プログラミングの生産性が非常に高く、「一般化」という用語で一般化できる理由です。残念ながら、この特定の一般化は実行時にコストがかかります。

通常、このコストは実質的ではありませんが、仮想メソッド呼び出しとオブジェクト作成のオーバーヘッドが違いを生むアプリケーションがあります(特に仮想メソッドはメソッド呼び出しのインライン化などの他の最適化を妨げるため)。これは、C ++に大きな利点がある場所です。テンプレートを使用して、実行時に何も影響を与えないが、必ずしもOOPよりもポリモーフィックではない異なる種類の一般化を実現できます。実際、OOPを構成するメカニズムはすべて、テンプレートテクニックとコンパイル時の解決のみを使用してモデル化できます。

そのような場合(そして確かに、それらはしばしば特別な問題のドメインに制限されています)、C ++はC#および同等の言語に対して勝ちます。

グラフィックスの場合、標準のC#グラフィックスクラスは、C / C ++を介してアクセスされるGDIよりもかなり低速です。 これは言語そのものとは関係がなく、トータルの.NETプラットフォームとは関係ありませんが、グラフィックスはGDIの代替として開発者に提供されるものであり、そのパフォーマンスは非常に悪く、あえてグラフィックスをやることさえしません

グラフィックライブラリの速度を確認するために使用する簡単なベンチマークがあり、それは単にウィンドウにランダムな線を描画するだけです。 C ++ / GDIには10000行がありますが、C#/ Graphicsではリアルタイムで1000行を実行するのは困難です。

ガベージコレクションは、Java#をリアルタイムシステムに使用できない主な理由です。

  1. GCはいつ行われますか?

  2. 所要時間はどのくらいですか?

これは非決定的です。

C#のパフォーマンスがC ++に匹敵するかどうかを判断する必要があり、そのためのテストプログラムをいくつか作成しました(両方の言語でVisual Studio 2005を使用)。ガベージコレクションがなく、言語(フレームワークではない)のみを考慮する場合、C#のパフォーマンスは基本的にC ++と同じであることが判明しました。メモリの割り当てはC ++の場合よりもC#の方が高速であり、データサイズがキャッシュラインの境界を超えて大きくなると、C#の確定性はわずかに低下します。ただし、これらはすべて最終的に支払いが必要であり、ガベージコレクションによるC#の非決定的なパフォーマンスヒットという形で多大なコストがかかります。

通常どおり、アプリケーションによって異なります。 C#がおそらく無視できるほど遅い場合と、C ++が5または10倍速い場合、特に操作を簡単にSIMDできる場合があります。

それはあなたが求めていたものではないことはわかっていますが、C#はC ++よりも書く方が速いことがよくあります。

C / C ++は、大規模な配列または(任意のサイズの)配列に対する重いループ/反復があるプログラムで非常に優れたパフォーマンスを発揮できます。これは、ほとんどすべてのグラフィックス操作の根底に重い配列操作があるため、グラフィックスが一般的にC / C ++で高速になる理由です。 .NETは、すべての安全性チェックのために配列のインデックス付け操作が遅いことで有名です。これは、特に多次元配列に当てはまります(そして、長方形のC#配列は、ギザギザのC#配列よりもさらに遅くなります)。

C / C ++のボーナスは、ポインターを直接使用し、Boost、 std :: vector 、その他の高レベルコンテナー、および inline 可能なあらゆる小さな機能。可能な限り、昔ながらの配列を使用してください。はい。JavaまたはC#で行ったのと同じことを達成するには、高レベルのコンテナーを避けるために、より多くのコード行が必要になります。動的なサイズの配列が必要な場合は、 new T [] を対応する delete [] ステートメントとペアにすることを忘れないでください(または stdを使用します: :unique_ptr )&#8212;余分な速度の代価は、より慎重にコーディングする必要があることです。しかしその代わりに、マネージドメモリ/ガベージコレクターのオーバーヘッドを取り除くことができます。これは、Javaと.NETの両方のオブジェクト指向プログラムの大規模な実行時間の20%以上になります。メモリアレイのインデックス作成コスト。 C ++アプリは、特定の特定の場合にいくつかの気の利いたコンパイラースイッチの恩恵を受けることができます。

私は、C、C ++、Java、およびC#のエキスパートプログラマです。最近、後者の3つの言語でまったく同じアルゴリズムプログラムを実装することはほとんどありませんでした。このプログラムには、多くの数学演算と多次元配列演算がありました。これを3つの言語すべてで大幅に最適化しました。 結果は、厳密ではない比較で通常見られるものの典型でした:JavaはC#よりも約1.3倍(ほとんどのJVMはCLRよりも最適化されています)、C ++のrawポインターバージョンはC#よりも約2.1倍高速でした。 C#プログラムは安全なコードのみを使用していることに注意してください&#8212; unsafe キーワードを使用する前にC ++でコーディングすることをお勧めします。

誰もが私がC#に対して何かを持っていると思わないように、C#はおそらく私のお気に入りの言語だと言って締めくくります。これは、これまで出会った中で最も論理的で直感的で迅速な開発言語です。プロトタイピングはすべてC#で行います。 C#言語には、Javaに対して多くの小さな微妙な利点があります(はい、Microsoftがゲームに遅れて入り、おそらくJavaをコピーすることによってJavaの多くの欠点を修正する機会があったことを知っています)。 Javaの Calendar クラスに乾杯しますか? MicrosoftがCLRと.NET JITterを最適化するために実際の努力を費やした場合、C#が真剣に引き継ぐ可能性があります。私は彼らがまだC#言語で多くのことを行っていないことに驚いていますが、強烈なコンパイラの最適化でフォローアップしてみませんか?たぶん私たち全員が請うなら。

&gt;私が聞いたことから...

あなたの難しさは、聞いたことを信頼できるかどうかを判断することにあり、このサイトで返信を評価しようとすると、その難易度が繰り返されるだけです。

ここで人々が言うことは、最初に聞いたものよりも信頼できるかどうかをどのように決定しますか?

1つの方法は、証拠を求めることです。

「C#がC ++よりも高速であることが判明している領域がある」と誰かが主張するとき」 彼らにそれを言う理由を聞いて、測定値を見せるように頼み、プログラムを見せるように頼みます。時々、彼らは単に間違いを犯しただけでしょう。時には、彼らが真実であると示すことができる何かを共有するのではなく、単に意見を表明していることがわかります。

多くの場合、情報と意見は人々が主張する内容にまちまちであり、あなたはどちらがどれであるかを試してみて整理する必要があります。たとえば、このフォーラムの返信から:

  • &quot; http://shootout.alioth.debianでベンチマークを確認してください。 org / とても懐疑的に これらは主に算術コードをテストし、 ほとんどの場合、似ていない コードを作成します。&quot;

    本当にそうなら &quot;これらが主にテストするものを理解する 算術コード&quot; は、 著者が持っているかどうか自問してください 彼の主張が true。

  • &quot;これはかなり役に立たないテストです。 個々のプログラムは 最適化された;なんとかスピードアップできました それらのいくつかは4-6回以上で、 比較を明確にする 最適化されていないプログラム間の かなり愚かな。&quot;

    著者が持っているかどうかを自問する 彼が管理していることを実際に示しました それらの一部を4〜6倍高速化する 回以上」 -簡単に主張できます!

.NET言語はC ++コードと同じかそれ以上高速ですが、 .NETランタイムは GC (たとえ一時停止について非常に巧妙であっても)。

そのため、一時停止することなく一貫して高速に実行する必要があるコードがある場合、ランタイムGCに細心の注意を払っていても、.NETはある時点でレイテンシを導入します

「並外れた並列」問題の場合、Intel TBBとOpenMPをC ++で使用すると、C#とTPLで行われた同様の(純粋な数学)問題と比較して、パフォーマンスが約10倍向上します。 SIMDはC#が競合できない領域の1つですが、TPLにはかなりのオーバーヘッドがあるという印象も受けました。

そうは言っても、パフォーマンスを重視するタスクにのみC ++を使用するのは、マルチスレッドを実行して結果をすばやく取得できることがわかっている場合だけです。それ以外の場合は、C#(および場合によってはF#)で十分です。

これは非常に曖昧な質問であり、実際の決定的な答えはありません。

たとえば、パフォーマンスは確かにはるかに優れているため、C#よりもC ++で作成された3Dゲームをプレイしたいです。 (そして、私はXNAなどを知っていますが、それは本物に近づきません)。

一方、前述のとおり。必要なことをすばやく実行できる言語で開発し、必要に応じて最適化する必要があります。

理論的には、長時間実行されるサーバー型アプリケーションの場合、JITでコンパイルされた言語は、ネイティブにコンパイルされた対応する言語よりも非常に速くなります。 JITでコンパイルされた言語は通常、かなり低レベルの中間言語に最初にコンパイルされるため、とにかくコンパイル時に多くの高レベルの最適化を行うことができます。大きな利点は、JITがアプリケーションの使用方法に関するデータをどんどん取得して、コードのセクションをその場で再コンパイルし続けることができることです。最も一般的なコードパスを配置して、分岐予測をできるだけ頻繁に成功させることができます。多くの場合、一緒に呼び出される別々のコードブロックを再配置して、両方をキャッシュに保持します。内部ループの最適化により多くの労力を費やすことができます。

これは.NETまたはJREのいずれかによって行われるとは思いませんが、私が大学にいたときに研究されていたので、これらの種類のものが実際の世界に進むと考えるのは不合理ではありませんすぐにいくつかのポイント。

集中的なメモリアクセスを必要とするアプリケーション。通常、画像操作は、マネージド(C#)よりもアンマネージド環境(C ++)で記述した方が適切です。ポインター演算を使用して最適化された内部ループは、C ++での制御がはるかに簡単です。 C#では、同じパフォーマンスに近づくために、安全でないコードに頼る必要がある場合があります。

C ++およびC#で同等の vector をテストしました- List および単純な2D配列。

Visual C#/ C ++ 2010 Expressエディションを使用しています。どちらのプロジェクトもシンプルなコンソールアプリケーションです。標準(カスタム設定なし)リリースおよびデバッグモードでテストしました。 私のPCではC#リストの実行が速くなり、C#では配列の初期化も速くなり、数学演算は遅くなります。

Intel Core2Duo P8600 @ 2.4GHz、C#-.NET 4.0を使用しています。

ベクターの実装はC#リストとは異なることは知っていますが、オブジェクトの保存に使用するコレクションをテストしたいだけです(そして、インデックスアクセサーを使用できるようになります)。

もちろん、メモリをクリアする必要があります( new を使用するたびに言いましょう)が、コードをシンプルに保ちたいと思いました。

C ++ベクトルテスト

static void TestVector()
{
    clock_t start,finish;
    start=clock();
    vector<vector<double>> myList=vector<vector<double>>();
    int i=0;
    for( i=0; i<500; i++)
    {
        myList.push_back(vector<double>());
        for(int j=0;j<50000;j++)
            myList[i].push_back(j+i);
    }
    finish=clock();
    cout<<(finish-start)<<endl;
    cout<<(double(finish - start)/CLOCKS_PER_SEC);
}

C#リストテスト:

private static void TestVector()
{

    DateTime t1 = System.DateTime.Now;
    List<List<double>> myList = new List<List<double>>();
    int i = 0;
    for (i = 0; i < 500; i++)
    {
        myList.Add(new List<double>());
        for (int j = 0; j < 50000; j++)
            myList[i].Add(j *i);
    }
    DateTime t2 = System.DateTime.Now;
    Console.WriteLine(t2 - t1);
}

C ++-配列:

static void TestArray()
{
    cout << "Normal array test:" << endl;
    const int rows = 5000;
    const int columns = 9000;
    clock_t start, finish;

    start = clock();
    double** arr = new double*[rows];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    finish = clock();

    cout << (finish - start) << endl;

    start = clock();
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i * j;
    finish = clock();

    cout << (finish - start) << endl;
}

C#-配列:

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i * j;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

}

時間:(リリース/デバッグ)

C ++

  • 600/606ミリ秒の配列初期化、
  • 200/270ミリ秒の配列充填、
  • 1秒/ 13秒のベクター初期化&amp;記入してください。

(はい、13秒、デバッグモードでリスト/ベクターに常に問題があります。)

C#:

  • 20/20 ms配列の初期化、
  • 403/440ミリ秒の配列充填、
  • 710/742 msリストの初期化&amp;記入してください。

まあ、それは依存します。バイトコードが(JITだけでなく)マシンコードに変換される場合(プログラムを実行する場合)およびプログラムが多くの割り当て/割り当て解除を使用する場合、 GC アルゴリズムは、メモリ全体を1回(理論的に)1回パスするだけでよいが、通常のmalloc / realloc / free C / C ++呼び出しは、呼び出しごとにオーバーヘッドを引き起こします(呼び出しオーバーヘッド、データ構造のオーバーヘッド、キャッシュミス;))。

つまり、理論的には可能です(他のGC言語でも)。

メタプログラミングを使用できないという極端な不利益は実際にはありません。ほとんどのプログラマーはとにかく使用しないため、ほとんどのアプリケーションでC#を使用します。

もう1つの大きな利点は、 LINQ &quot; extension&quot;などのSQLが提供することです。コンパイラーがデータベースへの呼び出しを最適化する機会(言い換えると、コンパイラーは、呼び出された関数がインライン化されているか、最適化された使用のために、LINQ全体を1つの「blob」」バイナリーにコンパイルできますが、私はここで推測しています)

C#で記述されたアプリケーションが高速で実行されているだけでなく、C ++で記述されたアプリケーションが高速で実行されていると思われます(C ++が古いだけでなく、UNIXも必要です...)
-質問は確かに-そのことは何ですか、ユーザーと開発者は不満を言っています...
私見、C#の場合、非常に快適なUI、ライブラリの非常に優れた階層、およびCLIのインターフェイスシステム全体があります。 C ++の場合、テンプレート、ATL、COM、MFC、およびOpenGL、DirectXなどのコードを既に実行および実行しているコードのすべてのシェバンがあります。 1秒で-強打!それが立ち往生しています。
C#で非常にシンプルかつ高速にコードを記述する(それを忘れないようにすると、エラーの可能性も高まります)。 C ++の場合、開発者はメモリリークを訴えます。つまり、クラッシュ、DLL間の呼び出し、および「DLL地獄」のことを意味します。 -サポートおよび新しいライブラリによる置換ライブラリの問題...
プログラミング言語のスキルが高いほど、ソフトウェアの特性(および速度)が高くなると思います。

私はこのように言います。より速いコードを書くプログラマは、現在のマシンを高速化するものについてより多くの知識を持っているプログラマであり、偶然にも、正確な低レベルおよび決定論的最適化手法。これらの理由から、これらの人々はC#ではなくC / C ++を使用する人々です。これを事実として述べるまで行きます。

&gt;結局のところ、答えはどこかにある必要がありますよね? :)

うーん、いいえ。

いくつかの回答が述べたように、質問は回答ではなく応答として質問を誘う方法で指定が不十分です。一つの方法をとるには:

そして、どのプログラムですか?どのマシン?どのOS?どのデータセットですか?

私が間違っていなければ、C#テンプレートは実行時に決定されます。これは、C ++のコンパイル時テンプレートよりも遅くなければなりません。

そして、非常に多くの他の人が言及した他のすべてのコンパイル時の最適化を取り入れると、実際にはより高速を意味する安全性の欠如...

私は、C ++が生の速度と最小メモリ消費の観点から明らかな選択肢だと思います。しかし、これはまた、コードの開発により多くの時間を費やし、メモリリークやnullポインタ例外の発生を防止します。

判定:

  • C#:より高速な開発、より遅い実行

  • C ++:開発が遅く、実行が速い。

コードで何を達成しようとしているのかによります。 VB.NET、C#、マネージドC ++の間にパフォーマンスの違いがあるのは都市伝説のようなものだと聞いたことがあります。ただし、少なくとも文字列の比較では、マネージC ++がC#のズボンを打ち負かし、それがVB.NETのズボンを打ち負かすことがわかりました。

言語間のアルゴリズムの複雑さを徹底的に比較したことは決してありません。また、各言語のデフォルト設定を使用しています。 VB.NETでは、変数などの宣言を要求する設定を使用しています。マネージC ++に使用しているコードは次のとおりです(ご覧のとおり、このコードは非常に単純です)。 .NET 4.6.2を使用してVisual Studio 2013の他の言語でも同じことを実行しています。

#include "stdafx.h"

using namespace System;
using namespace System::Diagnostics;

bool EqualMe(String^ first, String^ second)
{
    return first->Equals(second);
}
int main(array<String ^> ^args)
{
    Stopwatch^ sw = gcnew Stopwatch();
    sw->Start();
    for (int i = 0; i < 100000; i++)
    {
        EqualMe(L"one", L"two");
    }
    sw->Stop();
    Console::WriteLine(sw->ElapsedTicks);
    return 0;
}

パフォーマンスの面でC#とC ++にはいくつかの大きな違いがあります:

  • C#はGC /ヒープベースです。メモリアクセスの局所性がないため、割り当てとGC自体がオーバーヘッドになります
  • C ++オプティマイザーは、長年にわたって非常に優れたものになりました。 JITコンパイラーはコンパイル時間に制限があり、グローバルスコープが表示されないため、同じレベルを達成できません

プログラマーの能力に加えて、役割も果たします。私は、クラスが引数として値で渡された悪いC ++コードを見てきました。注意を怠ると、C ++で実際に悪化させる可能性があります。

これに触発されて、私はほとんどのプログラムで必要な一般的な指示の60%で簡単なテストを行いました。

C#コードは次のとおりです:

for (int i=0; i<1000; i++)
{
    StreamReader str = new StreamReader("file.csv");
    StreamWriter stw = new StreamWriter("examp.csv");
    string strL = "";
    while((strL = str.ReadLine()) != null)
    {
        ArrayList al = new ArrayList();
        string[] strline = strL.Split(',');
        al.AddRange(strline);
        foreach(string str1 in strline)
        {
            stw.Write(str1 + ",");
        }
        stw.Write("\n");
    }
    str.Close();
    stw.Close();
}

文字列配列とarraylistは、これらの命令を含めるために意図的に使用されます。

C ++コードは次のとおりです。

for (int i = 0; i<1000; i++)
{
    std::fstream file("file.csv", ios::in);
    if (!file.is_open())
    {
        std::cout << "File not found!\n";
        return 1;
    }

    ofstream myfile;
    myfile.open ("example.txt");
    std::string csvLine;

    while (std::getline(file, csvLine))
    {
        std::istringstream csvStream(csvLine);
        std::vector csvColumn;
        std::string csvElement;

        while( std::getline(csvStream, csvElement, ‘,’) )
        {
            csvColumn.push_back(csvElement);
        }

        for (std::vector::iterator j = csvColumn.begin(); j != csvColumn.end(); ++j)
        {
            myfile << *j << ", ";
        }

        csvColumn.clear();
        csvElement.clear();
        csvLine.clear();
        myfile << "\n";
    }
    myfile.close();
    file.close();
}

使用した入力ファイルサイズは40 KBです。

結果は次のとおりです。

  • C ++コードは9秒で実行されました。
  • C#コード:4秒!!!

ああ、これはLinuxでした... C#を Mono ...そして、g ++を使用したC ++。

OK、これはWindowsで得たものです&#8211; Visual&nbsp; Studio&nbsp; 2003

  • C#コードは9秒で実行されました。
  • C ++コード&#8211;恐ろしい370秒!!!
ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top