よく考慮したコーディングとパフォーマンスの関係

http://hacksoflife.blogspot.com.au/2015/01/the-four-horsemen-of-performance.html

1 comment | 1 point | by WazanovaNews 3年弱前 edited


Jshiike 3年弱前 edited | ▲upvoteする | link

Benjamin Supnik曰く、高いパフォーマンスをだせるソフトウェアは、高いパフォーマンスを目指したデザインプロセスが大切。「本当にひどい状態になったら、プロファイラで調べて直すから。」といっても色々積み重なると簡単には直せなくなると指摘しています。そして、ゲーム開発において遅いコードを生み出すパターンを挙げてくれてます。

1. 無駄なことをする

  • テーブルを再描画する際、ユーザが見える部分だけでなく、テーブル全体のデータを取得していないか?
  • 同じ値が計算されて何度も使われるケースで、都度計算し直していないか?
  • 必要とするのが現状のステートであるのに、描画の度にOpenGLのステートを更新していないか?
  • エディタプログラムを使ってドキュメントで大量のアイテムを編集するケースで、アイテムごとにUIを更新していないか?最後にまとめて更新すればよい。
  • 非効率なアルゴリズムの選択。
  • terrainをシェードするのにGPUを使うか?それとも、事前にシェードして、ディスクに保存するか?ほとんどのケースで事前に処理する方がよい。
  • レーシングゲームで、建物はどのレベルにも配置する必要があるか?それとも、ドライバーが見える範囲だけに収めるか。どこにでも配置すると、ディスクから読み込み、cullして、レンダリングする作業が余計にかかる。

2. 定数時間の非効率を放置する

  • 静的に保存できるのにmallocで動的にデータをアロケートする。
  • std::vectorでよいのにstd::mapを使う。mapはmallocを大量に呼び出してしまう。
  • スタティック関数やインライン関数でよいのに仮想関数を使う。
  • static_castでよいのにdynamic_castを使う。
  • キャッシュの局所性が弱いメモリ構造を採用する。

この影響が大きくなっている背景として、

  • CPUとメモリパフォーマンスのギャップが拡大している。L1キャッシュが3サイクルであるのにメインメモリへのキャッシュミスが300サイクルかかると、定数時間の係数部分の局所性が100倍になる。
  • デスクトップではそれほどではない(遅延を隠すために超高性能チップがかなりアグレッシブに働いてくれる。)定数時間の係数が、コンソールでは依然として相当悪い。モバイルでも同様。Mac Proではそこそこ動いてくれるヒドいコードは、iPhone 4Sでは悲惨な結果となる。
  • コードのほとんどで同じツールを使う傾向にある。よって、遅い定数時間のテクニックを採用するとコード全体に影響を与える。該当箇所を直すのではなく、全体を書き直す羽目に陥る可能性がある。

3. 余計な抽象化の影響

  • 個別の課題の解決に、一般的なソリューションを適用してしまう。
  • 簡単な問題を更に計算能力を必要する解決策で対処してしまう。
  • プログラム間に、シンプルな、だがパフォーマンスコストの高い抽象化を適用することで、特定の問題に直接対応する機会を失ってしまう。

具体的に起こりうるのは、

  • AABB(軸に平行な直方体)に対してトライアングルをクリップしたいだけなのに、アルゴリズムが、ホールのある二つの任意のポリゴンの交差をとってしまう。
  • drawingファンクションが、ユニバーサルトライアングル(色、テクスチャ、ポジションを伴うトライアングル)を描画し、アプリの全てのパーツにその形式での呼び出しを強制してしまう。
  • WorldEditorが必要な箇所でなく全体を再描画してしまう。

2014 Topアクセスランキング


Back