My life as an APE

というわけでの日本。VISAの手続きなども滞りなく終わり、ラーメン、牛丼、テンプラ、ハンバーガー等、主な目標は攻略済みだ。
久々の日本で体験した奇妙なことをいくつか。

●「検索サイトでしらべてネ」CMのなぞ
久しぶりにTVCMを見ると「検索エンジンでサーチ！」という様な文句＋クリック音＋ダイアログボックス的表示が目立って増えたようだ。
サイトURLを直接教えない点がまず、やや腑に落ちない。
更に考えると、日本語URLというのも発案されたいた気がするが、殲滅されたのだろうか？　とか、（プラグインインストールがかなり鬱陶しい）JWordというサービスもあった気もするけどどうなったのか？　と色々思い出す。

特定の検索語でのサーチエンジンサーチを推奨するのであれば、当然その語でのSEO（サーチエンジン最適化）を行っているのだろう。幾つかの広告代理店ではSEO業務も行っているらしいので、これはもしかすると、広告代理店に良い様にお金を差し上げるための、いわゆる一つの勿体無い話なのではないだろうか？

最近、とあるサイトのSEOを行ったが、SEO作業自体はなんというか、巷で言われるほど難しかったり奥の深いものではなさそうだった。
考えてみれば、サーチエンジン側のリソースが有限であり、サイトが星の数ほどある以上、それぞれのサイトのインデックス時に、それほどマジカルなインデキシング処理は行えない、と考えるのが自然だろう。

実体は奥が深くないのだが、その情報の非対称性を利用してSEO業界が成り立ち、どのサイト、どの書籍をみても核心はぼやかし、ミステリアスに表現している。そしてお値段設定も高めだ。なかなか微妙だ。

ところで、自分がSEOを行ったサイトでは、最終的に特定マイナーキーワードでGoogleランキング2位につけた。が、サイト名自体にキーワードを含まれておらず、ランキング1位はならず。残念～。

追記：いただいたコメントによると、どうもCMでのURL表示にはテレビ局側の自主規制が存在しているようだ。なんというか苦肉の策的だ。

TVCMのURL表示制限

余談だが、米国ではTVCMは費用対効果の面でとうに「手段の一つ」的な扱いになっており、日本風マーケティングのように「TVCMに予算集中投下～」的な施策はアンビリーバボーとのことだ。

●女性専用車両のなぞ
朝方に電車に乗るのも数年ぶりだが、予想していたよりも混雑が酷くなくて快適だ。すし詰めのものすごいラッシュを想像していたのだが、朝の常磐線は本が読めるくらいの混雑度で、運がよければ座ることもできる。

ホームで並んでいる最中に「場所が違いますよ」と注意されてはじめて気づいたのだが、知らない間に女性専用車両が大分ポピュラーな存在になっていて、たいていの路線で朝夕のラッシュ時に採用されているようだ。
なんとなくではあるが、ポリティカリーコレクト的には「女性専用車両」というのは好ましくないという印象があるが、実際にはどうなのだろうか？

実際の女性専用車両導入後の痴漢発生率の推移が気になる。
・潜在的に通常車両でのリスクが高くなっているのであれば、車両自体を廃止したほうが良いだろう。
・効果があるのであれば、車両全体を男性専用、女性専用に分断してしまえば、原理上は痴漢犯罪を撲滅できる筈だが、どうだろうか

●ビール横並びのなぞ
　「～プレミアム」といったビールが気になり夜コンビニに買いにいくと（夜中にコンビニに買い物にいけるのはとても便利だ）、どのメーカーも、ちょっとお高め、普通、発泡酒というグレードで揃っていて良く分からないことになっている。コンビニの棚も３×３のブランド×価格帯のマトリックス配列になっていて更に良く分からない。同ブランドで縦展開するよりは、（エビスのように）別ブランドで出した方が分かりやすいのでは、となぞが残る。
で、結局のところ「缶」がつや消しで一見美味しそうなビールを手に取ったのだが、お味のほどは微妙であった。

といったことを考えさせられる、初冬の東京であった。

ゲームプラットフォームとしてのPCが日本でも注目されてきているようだ。
もちろんフリーゲーム、オンラインゲームや特定ジャンルのゲームではPCゲーム市場は十分に存在してきていた。が、最近ではコンシューマ向けゲームを専業としてきたゲーム会社でもPCを含めたマルチプラットフォーム開発が視野に入っているという話を多く聞く。その理由としては下記のような点だろうか。
・PCゲームマーケットにベットすることによるリスク分散
　マルチプラットフォーム化の潮流、ロイヤリティフリー等の利点
・コンソールゲーム機のSW/HW構成（特にGPU仕様）がPC用SW/HWに近づいてきた点

また、アーケードゲームシステムでは一足先にPCアーキテクチャを採用したシステムが増えているが、こちらはメンテナンス製、アップグレードのしやすさ、開発工数削減などの要素諸々がアーケードシステムの要求に良くマッチしているからだろう。
タイトー TypeX
http://www.typex.taito.jp/topics.html
SEGA リンドバーグ
http://www.watch.impress.co.jp/game/docs/20061025/3dvf5.htm
Namco SystemN2
http://jp.nvidia.com/object/IO_16001.html

（パフォーマンスを要求する）PCゲーム開発については、長らく国内市場が存在しなかったこともあって日本国内のゲームデベロッパからは技術が失われて久しい（そうでなかったら御免なさいだ）。ということでコンシューマ機とPCゲームをクロスプラットフォーム開発する上で、個人的に気になる点を記しておきたい。

コンシューマ機との性能比較
同程度のHWプロファイルのPCとコンシューマ機を比較した場合、諸々の要素がかさなりあって、PC上で達成可能なパフォーマンスは大体同スペックのコンシューマ機の半分相当と見積もって妥当だ。例えば、Pentium3 733Mhzで動作しているコンシューマ機と同等のパフォーマンスを達成するには、Pentium3 1.5Ghz相当のCPUと（表現が難しいが）倍程度のスペックを持つGPUが必要だ。同様に現在市場に出回っているコンシューマ機相当の実効パフォーマンスを達成するにはもう1～2世代後のハイエンドPC程度があれば十分だ。
ゲームプラットフォームとしてPCアーキテクチャと専用機を比較した場合、技術面からみて注意が必要な点は

ドライバモデル、HW抽象化の必要性によるソフトウェア、APIの負荷

バス構成を原因とするメモリ帯域の違い

HWプロファイルが一定しないことによる工数の増大と最適化の限界

くらいかと思われる。

ドライバの負荷について
一般的にPCゲームではCPUがボトルネックになるといわれているが、その原因のほとんどはドライバ、APIの実装が寂しいことによるものだ。
コンシューマ機では、ドライバ・APIのボトルネックを取り除き、GPU側の最適化を枯らしたうえで、最終的にCPUボトルネックとなる事が多いことを考えると一周分状況が違うといえなくもない。
DirectX9やOpenGL等のドライバ内部では、主に描画コール発生時に内部で果てしなく、気の遠くなる処理が行われている。HWレジスタに各種レンダステートをマッピングさせるなどは楽なほうで、各種シェーダの入出力を一致させる処理ためにバイトコードをスキャンする等の一連の冗長な処理がHW仕様を隠蔽した分、暗黙のうちに行われている。またカーネルモード、ユーザモードの状態遷移処理もCPUサイクル負荷となる。
これらを防ぐためにドライバ呼び出しの回数を少なく、つまりBatchサイズを大きくすることが、PC上での最適化の定石とされている。

バッチサイズ
PCDirectX上では、バッチ化によってAPI呼び出し回数を少なくすることが常套手段だ。API呼び出し毎での描画プリミティブ数を多くするため、インスタンシングや、マテリアル・テクスチャ単位でのプリミティブソートなどが有効な手段となる。
PCゲームにおいて一般的な１シーンあたりの描画コール数は目安として～700回前後が適当とされている。一方で、同程度のHW性能を持つゲームコンソールではその５～15倍前後の描画コール発行数が標準的だ。もちろん無駄な描画コール数を減らすことはコンシューマ機でも重要だが、コンシューマ機では描画コール数を減らすことを目的として余分なCPUサイクルを消費しても逆効果なことが多い。

DX10では
DX10では、ステートオブジェクトの採用やシェーダへのシグネチャ採用によって、描画コール発行時のCPU負荷をできるだけ無くすために努力している。が、それでも本質的にAPI仕様にあわせたHW抽象化を行うことが必須となるため、ドライバ負荷の問題は今後も存在し続ける。
たとえば、リソース・マップ時のSwizzle←→LinearView変換など、ドライバが陰ながら努力（CPUサイクルを消費）している冗長な処理はDX10でも存在するし、今後のAPIセットでも残り続けるだろう。
また構造上APIコールがインライン化できない点もCPU負荷としては無視できない。
＃余談だが、C++ベースのゲームコードではCPUサイクルの10％前後が関数呼び出しの前処理、後処理で消費されていることがザラだ

D3DXヘルパ関数やD3Dエフェクト等は使わないほうが、かなり良い
PC上では、ドライバに直接かかわらないその他のソフトウェアコンポーネントについても、パフォーマンス最適化を意識していないものが多く、ゲーム・コア部分への採用には注意が必要だ。D3DX関数の多くは処理内容に比較して過剰のCPUサイクルを消費するため、パフォーマンスクリティカルなコードでは採用しないほうが（とても）良い。またD3DXEffectFramework、cgFx等のエフェクトについても生産性の向上には有用だが、実際のゲームアプリケーションには使わないことを（強く）お勧めしたい。
DX10のEffect実装については多く改善点が見られるが、仕様を吟味すると、Effect内部にデータをコピーする必要があるなど冗長であることは否めない。
こうしたドライバ、ソフトウェアのパフォーマンスについては、PC上ではハードウェアを高速化することによる対応（いわゆるフリーランチ）が主であり、ドライバ、APIソフトウェアの最適化によって高速化することに対してはインセンティブはそれほど高くない。ベンダにとって旧世代HWのドライバをチューニングすることは、（顧客サービスではあるが）ハードウェア買い替えを思いとどまらせる負のインセンティブともなりうる。

バス構成
PCアーキテクチャのHW構成を見たときに、パフォーマンス上でネックとなるのはAGP8X、PCIExpressなどで結ばれるメインメモリとGPUボード間のバス帯域だ。
GPU上のバス自体はボード上のローカルメモリとGPU間が広帯域な専用バスによって結ばれているため、大きな問題にならない。またCPU FSBの帯域については、前述のとおりソフトウェアレイヤが、メモリ帯域最適化よりもアルゴリズムが問題な状態なので、あまり意識する必要が無いのが現状だ。

AGP8Xバスの場合、仕様上は双方向毎秒8GB、片方向で4GBの帯域と定義されている。しかし実効レートではその10％以下、毎秒数百MBが妥当な帯域だ。この場合60Hzで動作するアプリケーションの場合、1フレームあたりで実際に使える有効帯域は3MB程度に制限される。このバスを行き来するデータは
・描画コマンドバッファ
・動的なコンスタントデータ
・パーティクルなどの動的頂点データ
・ムービーなどの動的テクスチャデータ
・トーンマッピング用データ等のGPUからのリードバック
等が考えられる。

このうち、描画コマンド、コンスタント、GPUからのリードバックなどについてはそれほど大きいサイズにはならない（描画コマンドで300KB前後）だろう。ダイナミック頂点、テクスチャを使う場合には帯域を十分に考えて更新する必要がある。
PCIExpressについては実際にHWを精査したことが無く不明だ。が同じく実効帯域については慎重に検討したほうが良いだろう。

各種HWへの対応
とくにパフォーマンスを追及するコードにとっては、多くのHWプロファイルに対応する必要があることは大きな足かせになる。CPUキャッシュのライン幅やキャッシュアルゴリズムを意識したコーディングは、PC上では実質的には難しい。
とはいえHWプロファイルが違うことに対する対応は、パフォーマンスを重視するコードについては標準的なHW構成ごとに違うソフトウェア実装をすることが標準的な対応だ。
テスト工数が指数的に増大するため現実的にはすべてのHWプロファイルに対してコードを用意することは不可能だが、CPU、GPUそれぞれ数種についてはそれぞれの組み合わせでプロファイルで下ベンチマークをとったうえで最適なコードパスを作成することが現実的なテクニックだ。

まとめ
コンシューマゲーム機のPC移植に当たって思わぬパフォーマンスネックになりがちな点をまとめた。また、こうしたパフォーマンス上の点以外にも、
・適当なプロファイル方法＆効果測定方法
・セキュリティ対策
・スレッド粒度やフレームレート等のOSの挙動の違い
などコンシューマ機と勝手の違う点は多い。
ともあれ、適切な手順を踏んで地雷を避ければPC上でもコンシューマ機との同時期のクロスプラットフォーム開発が十分可能なことは、多くのゲームベンダーが実証しているところだ。