ノルム計算プログラムにおいて、配列へのアクセスを一定間隔おきにし、その間隔と速度との関係を調べました。
まず、配列全体の要素数を32K（256KB）とし、２次キャッシュに収まるようにしました。次に要素数を16M（128MB）にして調べました。前者では１次キャッシュのヒット率を、後者では２次キャッシュのヒット率を調べていることになります。
キャッシュミスがおきた場合、１ライン分のデータは一度にキャッシュに読み込まれるため、ストライドが小さいと配列のサイズがキャッシュサイズ以上になっても数回に１回しかキャッシュミスは起こりません。しかし、ストライドが大きいほどキャッシュミスの頻度が増えるので次第に遅くなってゆき、ラインサイズ以上になると毎回キャッシュミスが起こるようになって速度は一定になります。
プログラム：rei2.c
実行結果（クリックすると詳細な図を表示）
|
|
| 図１．m×n＝32Kの場合 | 図２．m×n＝16Mの場合 |
図１では、m=16までは次第に遅くなっていき、その後はグラフが激しく変化しました。何度実行しても同じようなグラフが出てきました。１次キャッシュのラインサイズは64Byteなので、理論上はm=8でグラフは一定になるはずです。このような結果になった原因はよく分かりませんでした。
図２では、理想的な曲線が得られました。m=16までは遅くなっていき、その後ほぼ一定になっています。２次キャッシュのラインサイズは128Byteで、この結果と一致しています。
配列のサイズが１次キャッシュより大きくなっても、通常のアクセスでは２次キャッシュのアクセスは数回に１回しか起こらないため、それほど速度は低下しません。しかし、ストライドアクセスにして配列のサイズを変化させた場合、１次キャッシュからあふれると毎回２次キャッシュにアクセスするようになります。これにより１次キャッシュのサイズを測定することができます。
そこで、m=16に固定して、アクセスする要素の数と速度との関係を調べました。
プログラム：stride.c（main関数以外は上のrei2.cと同じてす。）
実行結果（クリックすると詳細な図を表示）
 |
 |
| 図３．ストライドアクセスにした場合の 要素数と速度の関係 |
図４．ストライドアクセスにしない場合（参考） |
図４はベクトルのノルム計算の結果です。
ストライドアクセスにしたことで全体的に速度が著しく低下していることが分かります。しかし、１次キャッシュあふれの影響を確認する事はできませんでした。なお、n=2Kにおける速度低下は２次キャッシュあふれによるものです。
Prev. ベクトルのノルム計算
Next ライン衝突、TLBあふれ
性能測定メニューへ戻る
最終更新日：2003/1/23