長い前置きも終わったところで、SSE4に話を移そう。このSADの計算を行う命令として、既にSSE2にPSADBWという命令が用意されている。命令フォーマットは、
PSADBW xmm1, xmm2
で、xmm1とxmm2にそれぞれ8つずつのByte値で前画像と現画像の値を入れると、SADsが計算されてxmm1に返される。面白いのは128bitモードだと、これを同時に2つ実行できるのだが、SADsの値も2つ返ってくる事だ。対してSSE4で用意されるMPSADBWは、
MPSADBW xmm1, xmm2, imm8
という構造をとる(Photo09)。面白いのは内部にSource Shifterを装備することで、この命令1個でまとめて8種類のSADsを計算できることだ。xmm1で前画像を、xmm2で現画像を8箇所分指定しておくと、その8つのSADsをまとめてxmm1に入れて返してくれるという仕組みだ。この結果、例えば8×8サイズのSADsの計算をSSSE3までとSSE4で比べた場合、これだけ差が出ることになる(Photo10)。
これに加えてもう一つ提供されるのがPHMINPOSUW(Photo11)である。要するにMPSADBWを使うと8つのSADsが1つのXMMレジスタに格納される。これをまとめて比較し、最小の値とその場所を返してくれるというのがPHMINPOSUWというわけだ。
ちなみにベンチマークセッションのプレゼンテーションでは触れられていなかったが、テクニカルセッションではフォーマット変換を容易にするPMOV命令(Photo12)も用意されていることが示されている。こうしたSSE4命令を使うことで、4割程度の性能改善がなされた、というのがベンチマークセッションにおける結論である。ちなみに純粋にスコアを比較すると、
Core2 Extreme QX6800 | 38sec |
Penryn Dual Core 3.33GHz | 22sec |
Penryn Quad Core 3.33GHz | 18sec |
となって、Quad Core同士だと2.1倍もの性能差となっているが、この性能差の要因はSSE4の他に動作周波数の差(3.33GHz vs 2.93GHz)やFSBの差(1333MHz vs 1067MHz)、キャッシュ容量の差(6MB vs 4MB)もあり、純粋にSSE4による性能アップは4割前後と見込んでいた。似た結果はテクニカルセッションでも示されており(Photo13)、やはりこちらも4割程度の性能差としている。
Photo12:要するにXMMレジスタに画像の値をロードするのに利用する命令である。 |
Photo13:こちらはWindows Media SDKを使っての比較。内部のロジックを大幅にSSE4対応に書き換えたものと思われる。 |
テクニカルセッションでは更に細かくSSE4の解説が行われたが、その紹介は項を改めるとして、とりあえずこのエンコード命令について触れておきたい。端的に言えば、MPSADBWを使うことにより、ベタなサーチパターンをインプリメントしても、そこそこの性能で動作するエンコーダが作りやすくなった、と言える。確かにいちいちSADsを計算しながら基準値と比較し、越えるようならSADsの計算を打ち切り次の場所に…なんて処理を高速化するのは難しいから、それよりはとにかくMPSADBWをつかってまとめてSADを求めて比較したほうが楽だし、それがそこそこの性能で動くのは喜ばしいとは思う。
しかし、逆に言えばこれに頼るとそれ以上のチューニングがしにくくなるし、大画面のエンコードは(絶対的なピクセル量が増える分)有利だと思うが、QVGAクラスの画面でこれがどこまで有効か? というのは(スループットとレイテンシが明確にならないと)ちょっと判断しにくいところだ。とはいえ、多くのエンコーダがこれに対応したバージョンを出しそうではある、というのが率直な感想ではある。ただこれをMulti-Threadで実行すると、今度はキャッシュやメモリアクセスがボトルネックになってきそうな気がする。そのあたりがどうか、というのは実際に実機を使って確認してみないと現状はなんともいえないというところだ。