この可能なL1キャッシュ書き込み最適化を実行するCPUはありますか？

L1キャッシュを備えたCPUが書き込みを行うと、通常、（データの更新に加えて）書き込み先のキャッシュラインがすでにL1キャッシュにあると想定して、キャッシュがそのキャッシュラインをダーティとしてマークします。 、後で更新されたデータを含む行を書き出します。

可能な最適化の1つは、キャッシュに書き込みの内容と以前のキャッシュの内容を比較させ、それらが同じである場合、その行をダーティとしてマークしないことです。これにより、キャッシュでライトバックを回避できる場合があるため、CPU製造元がこのロジックを実行するために必要なゲートに値するものとして、これをどのように認識しているかを確認できます。

私の質問：この最適化を実行するCPUはありますか？

なぜ私が尋ねているのかについての背景：一定のメモリアクセスを必要とするいくつかのコードを書いています。つまり、キャッシュの動作を聞くことができる人は、私がしていることを推測できないはずです。私のアクセスの一部は書き込みであり、このコードを実装する明白な方法では、書き込みの多くは、すでに存在するものと同じデータを書き込みます。書き込みを行う必要があるのは、データによっては、書き込んでいるデータが同じである場合とそうでない場合があり、同じアクションを実行することが重要であるためです。CPUが「no-change-write」を実際に書き込まないことによって最適化する場合、それはキャッシュの動作が私がやっていることによって異なり、それが私の目標を覆すことになることを意味します。

それで、この方法で書き込みを最適化しようとするCPUはありますか？

何時間もの検索の結果、この特定の最適化を使用するCPUを見つけることができませんでした。言及されている最適化のほとんどは、通常、読み取り/書き込み操作とデータアクセスのヒット/ミスに関連しています。

（7ページと） https://cseweb.ucsd.edu/classes/fa14/cse240A-a/pdf/08/CSE240A-MBT-L15-Cache.ppt.pdf

ただし、この最適化を実行できないという意味ではありません。一般に、CPUキャッシュラインのサイズにプログラムでアクセスすることが可能です。キャッシュレジスタの現在の値にアクセスすることも可能ですが、そうすることはやや危険です。間違ったときに間違ったレジスタにアクセスすると、実行中のプログラムに関連するレジスタが改ざんされている可能性があります。または、読み取ろうとしている行の内容を誤って変更する可能性があります。

レジスタのキャッシュの現在の値を取得する

さらに、すべての理論的なソリューションには、何らかのソフトウェア実装（アセンブラ）が必要です。私が見つけた最も近いものは、キャッシュ操作が可能なように見えるARMアーキテクチャに関連しています。これに加えて、目的のCPUのキャッシュラインのサイズも知っておく必要があります。キャッシュの内容をラインサイズの増分でメモリ内の2番目の場所に注意深く読み取り、それをレジスター（またはこの場合はL1キャッシュライン）に書き込まれるデータと比較できます。

CPUキャッシュの内容を読み取る

そこから、同じ書き換えを防ぐソフトウェアベースのシステムを考案できます。これは少し簡略化されていますが、存在するすべてのCPUにソリューションを適用できる必要があるためです。

キャッシュの一貫性に関連して私が見つけた別の可能性：

アキの一貫性に関するウィキペディアの記事からの関連する文章

この問題に関して、私の注意を引いた主なポイントは、Snarfingの説明でした。

これは、2番目のマスターがメインメモリ内の場所を変更するときに、キャッシュコントローラーがアドレスとデータの両方を監視して、メモリ場所の独自のコピーを更新しようとするメカニズムです。キャッシュにコピーがある場所への書き込み操作が確認されると、キャッシュコントローラーは、破損したメモリの場所の独自のコピーを新しいデータで更新します。

つまり、すでにメカニズムが存在している可能性があります。提案した最適化には使用されない可能性があるというだけです。読み取り/書き込み比較を実行するソフトウェアを実装する必要があります。

L1キャッシュへの書き込みは、非常にタイムクリティカルな操作です。

まったく同じデータを書き戻すことはかなりまれなようです。この特定のケースで物事をスピードアップする最適化は、全体で多くのスピードアップを得るつもりはありません。

一方、この最適化では、キャッシュメモリへの書き込みごとに古いデータと新しいデータを比較する必要があります。これをさらに悪化させるのは、書き込むデータが書き込み時に実際に利用可能でなければならないことです！

最近のCPUでは通常そうではありません。たとえば、書き込まれるデータはまだ計算中です。計算が完了する前でも、キャッシュは先に進み、必要に応じてキャッシュラインをロードし、キャッシュラインを変更済みとしてマークできます。キャッシュラインの実際の変更を除いて、すべての簿記はすでに実行できます。新しく書き込まれた結果と古いキャッシュラインデータを比較する場合、それは不可能です。

例として、Cコードがある場合、[i] = x / y; 除算x / yは、ほとんどのCPUで実行するのに非常に長い時間がかかります。ただし、結果を[i]に格納するために必要な作業のほとんどは、除算が完了するずっと前に行われました。唯一足りないのは、キャッシュラインへの8つの結果バイトの移動です。キャッシュラインをフラッシュする操作は、分割が完了するまで自動的に待機します。[i]を読み取る操作はリダイレクトされる可能性が高く、結果を除算器から直接取得します。

可能な最適化の1つは、キャッシュに書き込みの内容と以前のキャッシュの内容を比較させ、それらが同じである場合は、その行をダーティとしてマークしないことです。

そのような最適化は、CPUが何かをキャッシュに書き込むのに必要な時間の2倍になりませんか？これは、各キャッシュラインの書き込みに、解放されていない比較操作が伴うためです。

したがって、実際には、最適化は非常にあいまいな要素に依存します。平均的なソフトウェアがキャッシュ可能なメモリを同じデータで何度書き換えるかです。