ベンチマークかぁ - Underconstruction by Taiyo

どこで読んでブクマしたのか忘れたが、Early Performance Texting of the 8 Core Mac Proのベンチを見て、メニイコアのベンチマークって難しいと改めて思った。
メニイコアのコンピュータが操作性を向上させることは間違いないんだけど、特定のアプリケーションに的を絞ると、コア数なりのパフォーマンスが出てないってのも事実。そしてこの結果が「最適化されていない」というふうに言われがちだけど、処理によってはメニイコアの恩恵を受けにくいってことはもっと知られていいと思う。

3Dのレンダリングでは

スレッドをプロセッサ数まで増やして計算を分離できる処理で3DCGのレンダリングなんか典型的に、プロセッサの数を増やしたときに処理効率が向上する処理の例だ。画素ごとの演算は原則的におのおの独立した光の経路として計算され、他の光の経路のことを考えなくてもいいからね。
よくベンチマークで使われるCineBenchのソフトウェアレンダリングでは画像を縦にプロセッサ数で分割して、それぞれのエリアをそれぞれのCPUで計算する。それぞれのエリアでの計算負荷が均一なら理論値に近づくけど、空のように形状が少なくて演算負荷が極めて低い部分と地平線近辺のように多数の形状の前後判定を行わなければならないところでの差が大きいので、軽い部分のエリアを担当していたプロセッサは処理が終わり次第、まだ処理が終わっていないエリアの計算に参加する。このときの、担当エリアの持ち直しは、マルチプロセシングに必要なコストになる。
CineBenchのソフトウェアレンダリングでは、環境光を正確に計算する大域照明が使われている。ある部分の色の見え方を計算するために、そこへ到達する光を計算しているんだが、これは真面目にやると膨大な計算量になってしまうので、一度計算した結果を再利用することで高速化を計っている。床の中央での周囲からの光が一度計算されていたら、中央から1mm右も、左も、手前も奥も大して変わんないだろうから一度計算された結果を、周囲のの再利用状況を考慮しながら利用するんだ。
「一度計算された結果の利用」「周囲を考慮する」で出てくる処理がプロセッサの担当エリアの外側にあると、結果が同一でなくなり、連続したイメージにならなくなってしまうので、担当エリアは少し重なっている。これもまた処理の分割数を増やすためのコストだ。
ベースの計算がCineBenchよりも遅い手法になっているのでShadeがイイってわけじゃあないけど、Shadeでは画素ごとにことなるプロセッサが処理するようなレンダリングを行うので、理論値通りに処理効率が上がりやすい。

で、どーなのよお宅コア

3Dのレンダリングは趣味で使ってても数時間、実務では数時間から下手すると数日（映画用だと数千CPU使って数ヶ月とかいう例もあるよね）かかるような処理なので、高速化される可能性を常に検討しているし、製品にも反映されやすい。
Photoshopの処理は長くて数分、ほとんどの処理が秒単位で終了するし、処理ごとにメニイコアに対応した開発を行うのは非現実的だ。回転や拡大縮小のように一見分割可能に見える処理でも、アンチエイリアシングを行うための隣接ピクセル計算の最適化に影響が出るし。万を超えるピクセルでも一分以内で追わるご時世だ。拡大縮小されたイメージの画面表示はメニイコアに向いた処理ではあるし実際やってる風だけどベンチマークの対象とはなりにくいね。
動画や音声のエンコーディングはメニイコアに向かない典型的な処理だ。特にMPEGなどのストリーミング用では計算の多くを占める「前のフレームの結果との差を考慮した圧縮」は、前フレームの計算が終わっていなければ始められないし、前フレームの結果を知るためにはその前フレーム……の結果が必要になる。キーフレームごとに分割することは可能だろうけどコーデックやサポートしているオプションごとに異なるし、業務用だと、複数ファイルの同時エンコーディングで「マルチプロセッサ対応で処理効率を向上」と言えるので、開発資源を集中しにくい。
そう考えてベンチマークを見ると、普通に早いな。8Coreは。