作業中のプログラムをテストしたところ、-g を指定してコンパイルすると、実行速度が 3μs 速くなった (統計的に有意な変化) ことがわかりました。これは私には意味がありません - -g フラグはプログラムの実行に影響を与えるべきではないと考えていました。
なぜこれが起こっているのか誰にも教えてもらえますか？そして、プログラムの実行フローを変更するかどうか? 書かれているとおりに実行する必要があるため、-O を使用してコンパイルしていませんが、-g で命令の順序を変更して高速に実行できる場合は、明らかにそれを使用する必要があります。
したがって、-g フラグがプログラムに与える変更を正確に知る必要があります。
編集：実行するテストが増えるほど、t値が大きくなります（=統計的に有意な差になります）。これは間違いなく測定エラーではありません - 何かが起こっています.
他の人が言ったように、デバッグ シンボルは、コンパイラに (可能性が低い) バグがない限り、コードの制御フローを変更しません。
ただし、実行可能ファイルが大きくなり、実行されたコードがより多くのページに分散されるため、実行が変更されます。より多くのキャッシュ ミスと IO シグナルが期待できます。マルチタスク環境 (Linux/busybox システムでさえも) では、スケジューリングの動作がわずかに異なる可能性があります。
一方、あなたが説明するようなわずかな時間差を測定することは、それ自体が芸術です。おそらく、測定値が実行時間に影響するハイゼンベルク環境にいると思います。あなたの測定値は統計的に有意な偏差を示しているかもしれませんが、そのようなオプションがより高速なコードを作成すると言っていると解釈する際には非常に注意が必要です。
-g フラグは、実際に生成されたコードに 0 の変更を加えます。それは実行可能ファイルにデバッグ セクションを追加することです。これらのセクションは実行時に読み込まれませんが、デバッガーはそれらを読み込むことができます。実行可能ファイルが少し異なっているため、サイズが大きくなっています。あるバージョンと別のバージョンでページ フォールトが発生した場合、実行可能ファイルがディスクに保存される方法は変更されますが、コードは変更されません。
アセンブリを確認したい場合は、バイナリで objdump -d を実行して比較します
少なくとも汎用 OS で 3us を確実に測定するのは難しい作業ですが、3us の増加の妥当性には疑問があります。その数を使用して、そのような測定に影響を与えるすべてのランダムなものを排除しようとします。
サブルーチンの 1 つで -debug フラグと -g フラグを使用すると、コードで別の答えが得られます。そのため、理由はわかりませんが、プログラムの実行に確実に影響しています。