博士

ロボ子、今日はXbox 360のCPUに関する面白い話があるのじゃ。

ロボ子

Xbox 360ですか、懐かしいですね。どのようなお話でしょう？

博士

Xbox 360のCPUはIBM製の3コアPowerPCチップで、各コアに32KBの命令キャッシュと32KBのデータキャッシュがあるらしいのじゃ。L2キャッシュは1MBで、3つのコアで共有されるみたい。

ロボ子

キャッシュが少ないですね。メモリレイテンシも高かったとのことですが、何か対策はされていたのでしょうか？

博士

そう、そこで`xdcbt`という新しい命令が追加されたのじゃ。これは拡張プリフェッチ命令で、メモリからL1 d-cacheに直接データをフェッチして、L2をスキップするらしい。

ロボ子

`xdcbt`ですか。L2をスキップすることでレイテンシを減らすのですね。でも、L2をスキップするのは何かデメリットがあるのでしょうか？

博士

`xdcbt`はメモリコヒーレンシを保証しないから、注意が必要だったみたい。あるゲーム開発者が`xdcbt`をオプションで使用するメモリコピー routineを作成したところ、ヒープの破損によるクラッシュが発生したらしいのじゃ。

ロボ子

メモリコヒーレンシを保証しないと、複数のコアでデータが不整合になる可能性があるということですね。具体的には、どのような状況で問題が発生したのでしょうか？

博士

`xdcbt`でプリフェッチされたメモリが別のコアによって書き込まれると、2つのコアでメモリのビューが異なり、データが破損する可能性があるのじゃ。ゲーム開発者が`xdcbt`の使用を停止すると、クラッシュはなくなったらしい。

ロボ子

なるほど。しかし、その後、`xdcbt`を使用していないにもかかわらず、同じゲームでクラッシュが再発したとのことですが、それはなぜでしょう？

博士

原因は、分岐予測器が`xdcbt`命令を投機的に実行することだったのじゃ！投機的に実行された`xdcbt`は、実際に実行された`xdcbt`と同じように悪影響を及ぼすらしい。

ロボ子

分岐予測が誤って`xdcbt`を実行してしまうとは、驚きです。`xdcbt`をブレークポイントに置き換えることでクラッシュが解消されたとのことですが、それは`xdcbt`が実行されていないにもかかわらず、クラッシュの原因となっていたことを証明しているのですね。

博士

`xdcbt`は危険すぎるから、ゲームのコードセグメントで使用すべきではないと結論付けられたのじゃ。分岐予測器は不完全な履歴を使用するため、誤った予測をすることがあり、それが`xdcbt`の投機的実行につながるらしい。

ロボ子

命令一つでここまで深い問題が起こるとは、本当に奥が深いですね。メモリコヒーレンシの重要性を改めて認識しました。

博士

そうじゃな。しかし、`xdcbt`を使わずに、別の命令`xdcot`を使えばよかったのにのじゃ。…なんちゃって！