私は、キャッシュを意識したデータ構造の微調整 (たとえば、Michael Spiegel の論文のロックフリー スキップ ツリーまたは Herlihy らのホップスコッチ ハッシングを参照) と、たとえば同時配列処理中の偽共有の防止に関心があります。「sun.arch.data.model」プロパティを介して JVM ポインターのサイズを確認する方法は既に知っていますが、L1 キャッシュのキャッシュ ラインのサイズを確認する方法を見つけることができませんでした。
この情報は重要ではないことに注意してください。L1 ライン サイズの控えめな見積もりを引き続き使用できるためです (キャッシュを意識したデータ構造を微調整する場合は 64 バイト、偽共有を防止する場合は 256 バイト)。ただし、L1 キャッシュ プロパティを簡単に取得できる場合は、それを利用することもできます。
できることは、特定のストライドでメモリから 1 バイトを読み取る単純なループです。ストライドが 1 (バイト) の場合、反復ごとに 1 回行フェッチ ペナルティを支払う必要があります。スキップを 2 倍にすると、同じ反復回数ごとに行を 2 回フェッチするため、半分のパフォーマンスが期待できます。
ストライドでキャッシュラインのサイズに達すると、パフォーマンスの低下が停止することがわかります。これは、反復ごとに 1 行をフェッチするレベルに到達し、ストライドを再度 2 倍にしても変更されず、行をスキップするだけであるためです。 . これに伴う問題の 1 つは、CPU で HW ストリーム プリフェッチャーをトリガーし、事前に低いキャッシュ レベルでラインを待機させる可能性があることです。ストライド キャッシュ ライン サイズが 2 倍になると、ストリーム プリフェッチャーの一部がそれらよりも高速になるため、これがなくなる可能性があります (ストライド プリフェッチャーがさらに「役立つ」可能性はありますが、影響は劇的に小さくなるはずです)。
また、コードは、最後のレベルのキャッシュよりも大きなデータ セット (配列など) に対して実行する必要があることに注意してください。数 MB で十分です。