ほとんどのまともなコンパイラは、ポインタの間接参照をさまざまな程度に事前計算できることを確認しました（おそらくほとんどの分岐命令を削除します）が、私が興味を持っているのは、間接参照のコストが分岐点のコストよりも大きいかどうかです。生成されたコード。
ポインターによって参照されるデータが実行時にキャッシュにない場合、キャッシュフラッシュが発生する可能性があると思いますが、それを裏付けるデータがありません。
誰かがその問題に関する確かなデータ（または正当な意見）を持っていますか？
編集：いくつかのポスターは、分岐のコストに「一般的なケース」がないことを指摘しました：それはチップごとに大きく異なります。
キャッシュ内の間接参照よりも分岐が（分岐予測の有無にかかわらず）安価であるという注目すべきケースを知っている場合は、それについて言及してください。
これは状況に大きく依存します。
1 データがキャッシュ (L1、L2、L3) にある頻度、または RAM からフェッチする必要がある頻度はどれくらいですか?
RAM からのフェッチには約 10 ～ 40ns かかります。もちろん、それはキャッシュライン全体をそれよりも少し多く満たすので、次の数バイトも使用すると、「ひどく傷つく」ことはありません。
2 プロセッサは何ですか?
古い Intel Pentium4 は長いパイプライン ステージで有名であり、予測を誤った分岐から「回復」するには 25 ～ 30 クロック サイクル (2GHz で約 15ns) かかります。
3 状態はどの程度「予測可能」ですか?
分岐予測は最新のプロセッサで非常に役立ち、「予測不可能な」分岐にも非常にうまく対処できますが、少し害があります。
4 キャッシュはどの程度「ビジー」で「ダーティー」ですか?
キャッシュ ラインを満たすためにダーティ データを捨てる必要がある場合は、「データをフェッチする」時間に加えて、さらに 15 ～ 50ns かかります。
インダイレクション自体は高速な命令になりますが、もちろん、その直後のデータを次の命令が使用すると、データがL1キャッシュにある場合でも、その命令をすぐに実行できない場合があります。
一方、天気の良い日 (よく予測されている、キャッシュ内のターゲット、正しい方向に風が吹いているなど) では、分岐には 3 ～ 7 サイクルかかります。
最後に、もちろん、コンパイラは通常、何が最適かをよく知っています... ;)
要約すると、確実に言うのは難しく、あなたのケースで何が優れているかを判断する唯一の方法は、代替ソリューションをベンチマークすることです. 間接メモリ アクセスはジャンプよりも速いと思いますが、ソースがどのコードにコンパイルされるかを確認しないと、それを言うのは非常に困難です。
それは本当にあなたのプラットフォームに依存します。ターゲットCPUの中身を見ずして正解はありません。私のアドバイスは、テストアプリで両方の方法を測定して、顕著な違いがあるかどうかを確認することです.
私の本能は、最新の CPU では、関数ポインターを介した分岐と条件付き分岐の両方が分岐予測子の精度に依存しているため、予測子に同様のワークロードが提示された場合、2 つの手法から同様のパフォーマンスが期待できるということです。(つまり、常に同じように分岐する場合は、高速であると考えてください。予測が難しい場合は、問題があると考えてください。) しかし、確実に知る唯一の方法は、ターゲット プラットフォームで実際のテストを実行することです。
プロセッサによって異なりますが、使用しているデータのセットによっては、分岐の予測ミス (場合によっては命令の順序が正しくない) によって引き起こされるパイプライン フラッシュは、単純なキャッシュ ミスよりも速度に悪影響を与える可能性があります。
たとえば、PowerPC の場合、実行されなかった (しかし実行されると予測された) 分岐は約 22 サイクル (パイプラインを再充填するのにかかる時間) かかりますが、L1 キャッシュ ミスは 600 メモリ サイクルほどかかる場合があります。ただし、連続したデータにアクセスする場合は、分岐せずに、データのセットごとに 3 サイクル (分岐と取得が予測される分岐) のコストでプロセッサにデータのキャッシュミスをさせたほうがよい場合があります。再処理します。
要するに、自分でテストしてください。答えは、すべての問題に対して決定的なものではありません。
プロセッサは、どの命令が実行される可能性が高いかを計画するために条件付き回答を予測する必要があるため、命令の実際のコストは重要ではないと言えます。
条件付き命令は、プロセスフローを予測できないものにするため、効率が悪くなります。