ループの後ろで変数を宣言するのか、ループの中で宣言するのか？ - ページ 10

[Alexey Navoykov]

Vict:

時間＝1018
sum = 894782460
時間 = 371
sum = 894782460

なぜかわかりませんが、µlはそれを追い越しました（より複雑なrand()の亜種も同様です）。

そして、私にとっては、ループから外すということは明白です。

そうなんです、私もVSで試してみたのですが、なぜか全く最適化されないんです、こんな単純なバリアントなのに・・・実はこれに尽きるんです。

char *st = new char[23];
memcpy(st, "12345678qwertyuioasdfgh", 23);
sum += st[i % 23];
delete[] st;

[Alexey Volchanskiy]

Alexey Navoykov:

そうですね、私もVSで試してみましたが、こんなに簡単なオプションなのに、なぜか少しも最適化されていません・・・要するに、こういうことです。

プロジェクトの 設定で、すべての最適化を有効にしましたか？わかりにくい場合は、アセンブラのリストを生成できるようにして、それに目を通すと、とても勉強になりますよ。

[Alexey Navoykov]

興味本位でC#でもテストしてみることにした。 結果は速度がほぼ同じなだけでなく、C++よりもはるかに高速に動作することがわかった。

public class Program
{
  public static void Main()
    {
        int count = (int)10 e6;

        {
            var watch = System.Diagnostics.Stopwatch.StartNew();
            int sum = 0;
            for (int i = 0; i < count; i++)
            {
                string st;
                st = "12345678qwertyuioasdfgh";
                sum += st[i % 23];
            }
            Console.WriteLine("Sum: {0}, Time: {1} ms", sum, watch.ElapsedMilliseconds);
        }

        {
            var watch = System.Diagnostics.Stopwatch.StartNew();
            int sum = 0;
            string st;
            for (int i = 0; i < count; i++)
            {
                st = "12345678qwertyuioasdfgh";
                sum += st[i % 23];
            }
            Console.WriteLine("Sum: {0}, Time: {1} ms", sum, watch.ElapsedMilliseconds);
        }

        Console.ReadKey();
    }
}

結果

総和：894782460、時間：69ms。

総和：894782460、時間：56ms

そして、ここにC++でのアナログがある。

総和：894782460、時間：2947ms

総和：894782460、時間：684ms

VS 2019でテストしています。すべての最適化が有効になって います。

そんなC++はくそくらえだ)

p.s. C# での結果はテストによって大きく異なりますが、平均してどちらのバージョンも同じように高速です。

[削除済み]

Alexey Navoykov

まずブレーキの理由を理解する必要があります。少し調べてみましたが、呼び出し以外はすべてインラインです。

0x41a727 <main()+119>   callq  0x48e1a0 <_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE10_M_replaceEmmPKcm>

libstdc++ に収まっています。つまり、ほとんど裸のループの背景では、関数呼び出しそのものがボトルネックになっている（...replaceEmmPKcmからも何度か呼び出しがある）。コンパイラは、1つの翻訳ユニット内で最適化することができます。LTO（Link Time Optimization）といって、リンクの段階で最適化する方法があります。しかし、私はそれを使っていない、今はやらないだろう。まあ、特に複雑なことはありません - コンパイラ/リンカに渡す - fltoオプション（しかし、私はいくつかのプラグインが不足している）、それを把握するにはあまりにも怠惰な+ libstdc++を再構築する必要があるかもしれません。

今後予定されているモジュールのネジ止め（C++20以降）に関連したコードの最適化についてはどうなるのでしょうか？どうでしょう、vsで試してみてはいかがでしょうか、全ては生もの、実験的なものですがhttps://habr.com/en/company/pvs-studio/blog/328482/

c++'u will be missed )).

[Alexey Volchanskiy]

Alexey Navoykov:

興味本位でC#でもテストしてみることにした。 結果は速度的にほとんど変わらないだけでなく、C++よりも一桁速く動作している。

結果

総和：894782460、時間：69ms

総和：894782460、時間：56ms

そして、ここにC++でのアナログがある。

総和：894782460、時間：2947ms。

総和：894782460、時間：684ms

VS 2019でテストしています。すべての最適化が有効になって います。

そんなC++はくそくらえだ)

p.s. C#の結果はテストによって大きく変動しますが、平均するとどちらのバージョンも同じ速度です。

Br-r-r-r-r、まさか！？シャープはいつも純プロに2倍以上の差をつけてるんだから、企画を 出せよplz。

[prostotrader]

小さな子供たち :)

おもちゃを10ページに引き伸ばしたとか...。

[Alexey Navoykov]

Vict:

ここで、まず遅さの理由を理解する必要がある。少し調べてみましたが、呼び出し以外はすべてインラインです。

libstdc++ に収まっています。

ということで、今回のケースでも、毎回メモリを確保し、削除することを把握したようです。

char *str = new char[23];
...
delete str;

ちなみに、前回は間違った結果を出してしまったかもしれません。 x86モードだった可能性が高いです。現在、x64モードでテストしていますが、C++による結果はずっと良くなっています。

1）〜2000msec

2）～200ms（3倍速になります）。

Studioも最新版に更新しましたが、x86でも以前のテストより速くなったので、その影響もあるのでしょう。

C++はSharpにそれほど遅れをとっていない。 3倍程度の差しかない )

[削除済み]

Alexey Navoykov:

そのため、今回のケースでも毎回メモリを確保し、削除することを把握したようです。

ちなみに、前回は間違った結果を出してしまったかもしれません。 x86モードだった可能性が高いです。現在、x64モードでテストしていますが、C++による結果はずっと良くなっています。

1）〜2000msec

2）～200ms（3倍速になります）。

Studioも最新版に更新しましたが、x86でも以前のテストより速くなったので、その影響もあるのでしょう。

これでC++もシャープに負けるほど恥ずかしくはない。 約3倍の差しかないが )

というのは、わかっていないようです。一般に、テストはおもちゃのようなもので、ペイロードのないむき出しのループである。インライン化できない関数呼び出し でのロスを伝えようとしたのです。まだ未開発かもしれませんが、より良いテストとモジュールで、より興味深い結果を得ることができました。

[Alexey Navoykov]

Alexey Volchanskiy:

ブルルルルルル、まさか！？シャープは昔からクリーンプラスで2度おいしい、企画を出したのはplz.

[削除済み]

Vict:
プラス・モジュールのテストをしたほうがいい、結果はもっと面白い、まだ文書化されていないかもしれないが。

調べてみると、https://en.cppreference.com/w/cpp/compiler_support のコンパイラがモジュールを完成させていないので、見るべきものがないことが判明しました。