以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

Gustavo Duarte「コンピュータを待っている間にコンピュータがしてること」

2008.11.30のブログエントリ

What Your Computer Does While You Wait : Gustavo Duarte


node.jsのプレゼンのスライドで言及される最近のコンピュータのレイテンシの数字の元ネタにあたる解説記事

以下斜め読んだ内容
  • レイテンシとスループットを切り口にコンピュータのスペックを見る
  • ナノ秒(ns)/ミリ秒(ms)、秒(s)で計算
    • ナノ秒=10億分の1秒
  • スループットは、MB/秒かGB/秒
  • コンピュータの各構成要素の能力をはかる
  • プロセッサ
    • アホみたいに速い
    • Intel Core 2 Duo、3.0GHzだと、1クロックサイクルが0.33ナノ秒
    • 1クロックサイクルに命令1つ実行される
    • 0.33ナノ秒だと光は10cm移動できる
    • 現時点では命令コストはタダ同然になってる
  • L1キャッシュとL2キャッシュ
    • cpuが動いてるとき、システムメモリのread/writeが発生する
    • cpuはL1/L2キャッシュ経由でシステムメモリへアクセス
    • L1/L2はSRAMでできてる
    • SRAMDRAMよりも速く高価
      • DRAMはメインシステムメモリで使われる
    • プロセッサに組み込まれてる
    • レイテンシは低い
    • 命令レベルでの最適化をしたいときはコードサイズが検討される
      • L1/L2キャッシュに最適化したコードはL1/L2キャッシュへ一時的に渡されたり外に渡す必要のあるコードよりもずっと速くなる
  • メインメモリ
    • cpuからメモリ領域のデータにアクセスするとき、そのデータはL1/L2キャッシュにプールされている、もしくはメインメモリからL1/L2へ渡されている必要がある
    • 250クロックサイクル
      • 83ナノ秒
      • メインメモリからのデータの呼び出しにかかる時間
    • cpuが何もしないで待っている時間が発生するレベル
  • 現実のメインメモリのレイテンシは各種要因に左右される
    • アプリケーション
    • CAS latency
    • RAMの仕様
    • プロセッサのプリフェッチの仕組みの性能
      • 実行したコードによってcpuがあるデータを参照しないといけないとき
      • cpuがいかに速く保存されてるメモリ領域をつきとめるか
      • cpuからアクセスできるようにいかに手際よくキャッシュに保存しておけるか
  • L1/L2/メインメモリのパフォーマンス比較の詳細については良記事あるから読め
  • いわゆるVon Neumann bottleneck
    • cpu/メモリ間のボトルネックとして引き合いにだされる

-

  • ノースブリッジとサウスブリッジの間のDMIの帯域が8GB/秒とする
    • ノースブリッジ
    • サウスブリッジの間の帯域が10G/秒
    • 8GBのメインメモリのデータ8GBは1秒以内に読み込める
    • 10GB/秒はあくまで理論上の最大値であって実際は無理
    • メインメモリの回路上で色々な遅延が発生する
  • メモリへのアクセス時には色々な待ち時間がバラバラに発生してる
    • データアクセスのための電気的プロトコルが遅延を生むタイミングがいろいろある
      • あるメモリ行の選択後
      • ある列の選択後
      • データの読み込みが信頼性が確保される前
      • etc
    • コンデンサを使うとき、データが破壊されないように定期的にメモリ上のデータをリフレッシュする必要がある
      • このリフレッシュによってさらにオーバーヘッドが発生する
  • メモリへの連続アクセスは高速にできるケースもある
    • 連続アクセスにおいても遅延は発生するし、ランダムアクセスだともっと遅延は大きくなる
  • マザーボードのサウスブリッジ側はレイテンシのてんこもり
    • 色々なバスがある
      • PCIe
      • USB
      • ethernet(無線/有線)
      • 周辺機器
    • ハードディスクはメインメモリが速いと感じるくらい遅い
  • 各レイテンシをオフィスの比喩でみてみると・・・
    • L1:机から紙を1枚とる(3秒)
    • L2:本棚から本を取り出す(14秒)
    • メインメモリ:部屋を出て階下でお菓子を買う(4分)
    • ハードディスク:オフィスを出て世界放浪の旅に出る(1年3か月)
  • コンピュータの作業の大半は、ディスクI/O
    • これは、インメモリバッファが使いつくされるとデータベースの性能は壁にぶち当たるでもある
    • システムパフォーマンスアップのために、バッファ用に大量のRAMや高速なハードドライブが投入される理由でもある
  • ハードディスクのパフォーマンスのネックはシークにある
    • read/writeヘッドの移動、プラッターを回転させて、アクセスしたいセクターを特定、ヘッドが正しい位置にくるようにプラッターの回転
    • プラッターの回転速度を測る指標がディスクRPM
    • ディスクシークタイムについては、Google創業者二人が院生時代に書いた良い論文ある
  • ファイルサイズの大きい1ファイルをディスクから読み取る場合
    • シークがないので速度は上がる
  • ファイルシステムデフラグ
    • ディスクの中身を隙間がないようにする
    • シークタイムを最小化させるため
    • スループットをアップさせるため
  • スループットの安定化よりもシークタイムや単位時間当たりにできるランダムなI/Oオペレーションのサイズの方が重要
  • SSDはランダムなread/writeで性能が高いのでハードディスクの有力な代替物
  • ハードディスクキャッシュ
    • パフォーマンスアップにつながる場面がある
    • 750GBのハードディスクの16MBのハードディスクキャッシュの場合
      • 全体の容量の0.002%なので無意味?にみえる。
    • 書き込みをキューとしてまとめて一括してwrite処理を実行する
    • 一括writeのメリットは、ヘッドとプラッターの位置の調整コストを最小化できる点
    • 読み出し(read)についても一括して実行するのでwriteと同種の効率化が得られる
    • Linux KernelMLでのLinusのポストも参照
    • OSやハードディスクのファームウェアはこの手法での最適化に注力されてる
  • その他のスループットはどうか?
    • ネットワークや他のバス
    • firewireは図には入ってるが、Intel X48チップセットではネイティブサポートされてないバス
    • ネット接続のレイテンシだけみる
  • ネット接続
    • googleのような高速なウェブサイトで45ミリ秒のレイテンシ
    • ハードディスクに匹敵する
      • ハードディスクはメインメモリ層から5層分したのレイヤー
    • 家庭などのネット環境だと、ディスクのread時のレイテンシより遅い
    • 昔Sunが謳ってた「ネットワークこそコンピュータ」は現実的になってる