博士

やあ、ロボ子！今日のITニュースは、プログラム最適化の奥深〜い話じゃ。

ロボ子

博士、こんにちは。最適化、ですか。なんだか難しそうですね。

博士

ふむ、今回のテーマは「分岐予測」！これが逆効果になる場合があるというのじゃ。

ロボ子

分岐予測、ですか？確かCPUが次に実行するコードを予測する技術でしたよね。

博士

そうそう！特にトランザクション処理システムで、「送信」パスを高速化したいのに、「破棄」パスばかり予測されると困るのじゃ。

ロボ子

なるほど。ほとんどのリクエストが破棄される場合、CPUがそちらばかり予測してしまうんですね。

博士

その通り！で、記事によると、ARMの分岐予測命令とか、x86の命令プレフィックスとか、色々試したみたいじゃが…

ロボ子

でも、現代のプロセッサでは無視されるものもあるんですね。

博士

そうなんじゃ。C++20の`[[likely]]`や`[[unlikely]]`属性も、コンパイラにヒントを与えるだけで、分岐予測器自体は変わらないみたい。

ロボ子

`[[likely]]`と`[[unlikely]]`は、コードの並び替えに影響を与える可能性があるんですね。

博士

そこで！高レベルな解決策として、「モックトランザクション」の導入じゃ！

ロボ子

モックトランザクション、ですか？

博士

`should_send(t)`が`true`を返すモックトランザクションを大量に投入して、分岐予測器に「送信」パスが頻繁に実行されると思わせるのじゃ！

ロボ子

なるほど！でも、それだとオーバーヘッドが大きくなりませんか？

博士

そこは大丈夫！送信後に、ネットワークカードがモックトランザクションを識別して破棄するのじゃ！

ロボ子

賢い！それなら、オーバーヘッドを抑えられますね。

博士

Carl Cook氏の事例では、このモックトランザクションシステムで5マイクロ秒も高速化されたそうじゃ！

ロボ子

5マイクロ秒！すごいですね。最適化って奥が深い…。

博士

じゃろ？しかし、モックトランザクションを送りすぎて、本物のトランザクションが渋滞しないように気をつけないと…って、それじゃ本末転倒じゃ！

ロボ子

博士、それ、面白いオチですね！