SSE3で大幅アップするTMPGEnc 3の性能
では、実際にSSE3ではどのくらい性能がアップするのだろうか。まっさきにSSE3に対応したペガシス社のTMPGEnc 3を用いて、性能がどう変わったかを見ていくことにしよう。ちなみにTMPGEnc 3では、環境設定メニューにおいて、SSE3利用のオン/オフを切り替えることができるため、SSE3の効果を直接的に知ることができる。 167MBのDVフォーマットのAVIファイルに対して、標準、高画質、最高画質の3パターンで、SSE3の有無によってPrescott 3.2GHzの性能がどう変わるかを計測した。また、比較用に、NorthwoodコアのPentium 4-3.2GHzでの計測結果も併記する。
 |
|---|
| TMPGEnc 3の画面。操作の手順が上部に並べられ、いっそう使いやすくなっている |
 |
|---|
| TMPGEnc 3の環境設定パネル。さっそくSSE3のチェックボックスが追加されている |
 |
|---|
| TMPGEncによるMPEG2ファイル作成時間 |
見てのとおり、SSE3対応の効果は非常に大きい。10.3～13.4％もの性能向上を見せている。エンコード性能は比較的CPUクロックをリニアに反映するので、平均して12％のアップだとすれば、3.2GHzのCPUにとっては400MHz近くもアップしただけのゲインである。このように、SSE3はそのピンポイントに当たった用途においてはかなりのメリットをもたらすことがよくわかる。
ところで、TMPGEnc 3はSSE3のどの命令が用いられて高速化されているのだろうか？ 可能性として一番高いのは、LDDQU命令だ。これを活用すると、MPEG圧縮時に非常に大きな負荷となる「動きの検出」において、かなりの性能向上が期待できるからだ。動きの検出は、ある画素ブロックを、時間的に前、あるいは後ろのフレーム(画面)上に1ドット、あるいは半ドット単位でずらしながら重ね合わせていき、もっともよく一致する場所を探す、という、人間だったら10秒でめげてしまいそうな、とてつもない力業だ。ここで、画素ブロックのデータはSSEレジスタに入っているが、前、あるいは後ろのフレーム(画面)はメモリ上に置かれるわけだが、1ドット単位でずらしながらチェックする、ということは、要するに、1バイト単位でアドレスを変えながら読み出しては、(比較中の画素情報を収めた)レジスタと内容を比較していく、という作業になる。ここにLDDQU命令の出番がある。
LDDQU命令は、メモリ上の任意の位置から128ビットの整数データを読み出し、XMMレジスタに格納する、という命令だ。──もちろん、こんな基本的な動作が今までできなかったわけではない。同様の命令として、MOVDQAとMOVDQUという2つの命令が、SSE2で新設されている。
MOVDQAは動作が高速なのだが、読み出し先のメモリアドレスが16バイト(128ビット)境界に一致していなければならない、という制約がある。分かりやすくいえば、16進数で表現したアドレスの、最下位バイトが0のときにのみ利用可能で、残り、1～Fまでの場合には、無理に使うと一般保護例外を発生してしまう。これでは、動きの検出のように、1バイト単位でずらしながら──すなわち、最下位バイトを0～Fまで変化させながら読み出す用途には使えない。
もう一つの命令、MOVDQUのほうは、このような制約がないかわりに、動作は遅い。どれくらい遅いかは公表されていないが、遅いことは確からしい。
今回新設されたLDDQU命令は、MOVDQU命令同様、メモリアドレスの制限がない128ビットの読み出し命令だ。MOVDQU命令と異なるのは、MOVDQUが、本当に指定された128ビットだけを読み出そうとするのに対し、LDDQUは、末尾アドレス0をまたいで、その前後の256ビット分のデータを読み出してしまい、必要部分を合成する、というアプローチだ。以下のようになる。
●MOVDQU
欲しいデータ 56789ABCDEF01234
読み出し 567 89ABCDEF 01234
●LDDQU
欲しいデータ 56789ABCDEF01234
読み出し 0123456789ABCDEF 0123456789ABCDEF
MOVDQUは、本当に必要な部分だけを何回かに分けて読み出して合成する。不必要な部分に対してはメモリアクセスを行なわない、その意味では「正しい」「律儀な」動作だ。実際にどのような単位で読み出しているかは文献には記されていないが、今回実験した結果から、ほぼ間違いなく、上のように、メモリアドレスの末尾が0または8から始まる64ビット単位で、必要な部分だけをアクセスする、という動作のようだ。この場合、128ビットのデータを読み出すには3回のメモリアクセスが必要になる。これに対し、LDDQUは、アドレスの末尾が0から始まる2つの128ビットデータを読み出す。この、末尾が0からの128ビットリードというのは、ほかならぬ、高速なMOVDQA命令の動作にほかならない。つまり、LDDQUは2回のMOVDQA動作を行なったうえで、必要な部分を切り出す、という動作を行なう。
こうすることで高速化できるのなら、MOVDQU命令の内部的な動作を変更すればいい、と思われるかもしれないが、LDDQUは「いらない部分まで読む」ために、別の問題を抱える可能性がある。たとえば、最初の3のアドレスに対して書き込みをしようとしている命令が先に存在した場合、LDDQU方式では、この書き込みが完了するまでは読み出しを行なえない(そうでないと、更新前の、古い3のアドレスのデータを読んでしまうことになるため)。MOVDQUなら3の部分は読み出しを行なわないので、即座に読みに行ける。このようなケースではMOVDQUのほうが高速になる可能性がある。不必要な部分も読んでしまうLDDQUの弱点だ。動画圧縮においては、メモリ上には参照されるフレームのデータが収まっており、それは書き換えられることはないため、MOVDQUが有利なケースは考えにくいが、用途によってはMOVDQUのような動作が必要な局面があるため、残したものと思われる。
