I/Oとしてみたファイルシステム，データベース，そして描画

DirectX

ファイルシステムAPIを直接叩く時代からデータベースに丸投げという時代への移り変わりは，描画APIがCPUでフレームバッファを直接操作していた時代からGPU上でプログラマブルシェーダーを動かすようになった変化と似ているんじゃなかろうか，という話．
描画もファイルアクセスもカテゴリは同じI/Oなわけで，APIのセマンティクスが似ていlたとしても何ら不思議ではない．さらにセマンティクスの流行り廃れまで類似してしまうということもあり得るだろう．あなたがDirectX Graphicsで「Draw*Primitiveの最適化面倒すぎ」とか言っているその瞬間に，地球のどこかでデータベースの仕事をやっている人が似たような呪詛の言葉をはいているかもしれない．
ってネタで少し書いてみたいけど時間がなぁ．とりあえず方針列挙．

  • メモリ上のバッファを経由する時代から経由しない時代へ
  • メモリ(メモリ空間)へのオーバーレイのサポート．その流行と衰退．
  • バッチ処理によるカーネルコールの呼び出し回数の削減
  • そしてプログラムそのものを渡す時代へ

I/Oセマンティクスの分類って方向から攻めてみるのも手か．

  • ユーザが用意するメモリアドレスとデータ長を引数に取ってそこにR/W
  • システムが用意するメモリ(あるいはメモリ空間)が返ってそこにR/W
  • カーネルオブジェクト間で転送を行いユーザメモリは関与しないパターン
  • カーネルオブジェクトを操作するためのプログラムそのものを渡すパターン
  • バッチ処理サポート

とりあえずキーワードをメモしておく．というか読む人が読めば多分これだけで話の展開と結論までバレバレかと思う．

  • LinuxのsendfileカーネルコールとBitBlt
  • 柔軟な頂点フォーマット(FVF)及びIDirect3DVertexDeclaration9とデータスキーマ
  • ファイルのメモリマッピングとフレームバッファ
  • SQLとProgrammable Shader

そういえばCマガジン2004年5月号のWinFXに関する記事でLonghornの新しいファイルシステムの話題がちょっとだけ出ていた．「従来のファイルのようにデータをバイト配列として扱うとパフォーマンス的に不利であることが分かってきました」云々．何故不利なのかの説明が抜けていたが，私自身はDirectX Graphicsでの問題と似たような問題じゃないかと思っている．というわけでこれが結論．