「可能性が高い」および「可能性が低い」マクロの使用量は多すぎますか？

よく知られlikelyているunlikelyマクロとマクロは、コンパイラifが通常入力されるかスキップされるかを知るのに役立ちます。これを使用すると、パフォーマンスが多少（わずかに）向上します。

私は最近それらを使い始めましたが、そのようなヒントをどのくらいの頻度で使用すべきかわかりません。現在、エラーチェックで使用します。if通常はとしてマークされunlikelyます。例えば：

mem = malloc(size);
if (unlikely(mem == NULL))
  goto exit_no_mem;

それは問題ないように見えますが、エラーチェックはif非常に頻繁に発生し、その結果、上記のマクロが使用されます。

私の質問は、すべてのエラーチェックでマクロlikelyとunlikelyマクロを持っているのは多すぎるのifですか？

我々がそれに取り組んでいる間、彼らは他のどのような場所でよく使われますか？

私の現在の使用法では、リアルタイムサブシステムから抽象化するライブラリにあるため、プログラムはRTAI、QNXなどの間で移植可能になります。ただし、ほとんどの関数はかなり小さく、1つまたは2つの他の関数を直接呼び出します。多くはstatic inline機能です。

だから、まず第一に、それは私がプロファイルできるアプリケーションではありません。スタンドアロンアプリケーションではなくライブラリであるため、「ボトルネックを特定する」ことは意味がありません。

第二に、「これはありそうもないことを知っているので、コンパイラに伝えることもできます」というようなものです。私は積極的に最適化しようとしませんif。

あなたはそれであなたのコードを汚染しようとするほどひどいパフォーマンスが必要ですか？それはマイナーな最適化です。

• コードはタイトループで実行されますか？
• アプリケーションにパフォーマンスの問題がありますか？
• アプリケーションのプロファイルを作成し、この特定のループには多くのCPU時間がかかると判断しましたか？

yes上記のすべてに答えることができない限り、このようなことを気にしないでください。

編集：編集への応答。プロファイルできない場合でも、通常はホットスポットを推定できます。誰でも呼び出されるメモリ割り当て関数は、特にライブラリ全体で機能するためにマクロを1回使用するだけでよいため、良い候補です。

x86 / x64向けに書いている（そして20年前のCPUを使用していない）場合、__ builtin_expect（）を使用することによるパフォーマンスの向上は、あるとしてもごくわずかです。その理由は、最新のx86 / x64 CPU（ただし、Atomについては100％確実ではありません）には動的な分岐予測があるため、基本的にCPUはより頻繁に使用される分岐について「学習」します。もちろん、この情報は限られた数のブランチについてのみ保存できますが、可能なケースは2つだけです。（a）「頻繁に使用される」ブランチである場合、プログラムはその動的なブランチ予測の恩恵を受け、（b）それが「まれな」ブランチである場合、このようなまれな分岐（20 CPUサイクルの分岐予測ミスは、ブルームーンに一度発生したとしても悪くありません）。

注意：これは、現代のx86 / x64で分岐予測の重要性が低くなったことを意味するものではありません。まだ避ける必要があります。減少したx86 / x64上の__builtin_expect（）の重要性のみ（IIRC、約10〜15年前）-主に動的分岐予測のためです。

NB2：x86 / x64以外のプラットフォームの場合、YMMV。