ユメのチカラ: メモリアクセスは遅い

多くのプログラマにとってメモリアクセスの速度を気しなければならない状況というのはめったに無いが、OS、ライブラリ、コンパイラ、RDBMSなどの実装をする時には意識をしなければならない場合がある。 IA-32 Intel Architecture Optimization Reference Manual (order number 248966) をひもとくと6章にOptimizing Cache Usageというのがある。 マイクロベンマークの定番 lmbench http://www.bitmover.com/lmbench/ では、一次キャッシュ(L1)や二次キャッシュ(L2)を測定してくれる。例えば、わたしが利用しているノートだと、L1が1.776nsでL2が5.3490ns、メインメモリアクセスが139.4nsである。 Memory latencies in nanosecond

[ono_matope]

メモリも(L1/L2)キャッシュ重要という

[hamasta]

あとで読む

[advblog]

リストやハッシュはキャッシュに厳しいが配列はキャッシュに優しい。 > 何やら初体験の言い回し。

[mitsuki_engawa]

キャッシュ制御による高速化話

[hiromark]

"リストやハッシュはキャッシュに厳しいが配列はキャッシュに優しい"、むむぅ、なるほど。

[NOV1975]

あんまり詳しくないのでよくわからないんだけど、配列のアクセス一発目でそのとき使わない領域を含めた連続した領域が読み出されてキャッシュにのるから速いってこと？

[zetamatta]

曰く「リストやハッシュはキャッシュに厳しいが配列はキャッシュに優しい。」

[lockcole]

L1が1.776nsでL2が5.3490ns、メインメモリアクセスが139.4ns。CPUが速くなってもメモリが追いつけない。特にメモリのロック・同期方式にはまだまだアルゴリズムの改善余地ありとのこと。Rubyにおける改善案の紹介も。