真 もわ爛漫

しゃーら、しゃーらしゃーら

ストレージレイヤー談義、その3

じゃぁ最後に直球を投げるか

Numbers Everyone Should Know - High Scalability -

  • L1 cache reference 0.5 ns
  • Branch mispredict 5 ns
  • L2 cache reference 7 ns
  • Mutex lock/unlock 100 ns
  • Main memory reference 100 ns
  • Compress 1K bytes with Zippy 10,000 ns
  • Send 2K bytes over 1 Gbps network 20,000 ns
  • Read 1 MB sequentially from memory 250,000 ns
  • Round trip within same datacenter 500,000 ns
  • Disk seek 10,000,000 ns
  • Read 1 MB sequentially from network 10,000,000 ns
  • Read 1 MB sequentially from disk 30,000,000 ns

おしまいだ!(ぉぃ

いやいやいやいや(笑

ちょっと解説。つまりストレージレイヤーの特にメモリ対キャッシュの話になると、もうそれってストレージレイヤーだけじゃなくて対象アプリとマジtightに結びついちゃうんだよね、という感じなんです私的に。"Compress 1K bytes with Zippy" は単純なデータへのアクセスとかではないわけで、これをストレージレイヤーと比較してる点は恐るべきことです。やりたくありません

で、ディスクの何がやばいって「シークだけで10msかかるです」というところで、L2 リファレンスから memory リファレンスまで 100倍ないんだけど、次が、ええと、数えたくないほどの倍数あります!

というわけで続きをどうぞ(何

#ふむぅ。本気で考えるとプログラムサイズ、問題サイズ如何で「先生、HDDのキャッシュに収まりますっ」とかいうことになって余計にややこしいことに。ああでもやっぱり初回の10msはかかるんだよねーなんていう。あれあれそういえばARM系だとブランチ予測命令なんてあったりするとかいう噂があるのでコンパイラがすんげー頭が良ければ最初にメモリにprefetch出来る可能性も あr……

#もう私は考えるのに疲れたのでPythonで富豪します。さいなら