10月
31
x86版でアセンブラ化されているところは全てx64版でもアセンブラ化したので、ここいらでまたベンチマーク結果を載せておきます。基本的にはベタ移植なので速度はほとんど同じはずですが、ハフマンデコードに関してはメモリアクセス回数削減の効果が期待されるところです。なお、x64版のアセンブラ化の過程で、どちらに対しても適用できるデコードの高速化を行ったため、x86とx64の両方を再計測しています。
計測条件に関しては前回と同じです。エンコード対象の映像も同じです。
FourCC | 入出力 フォーマット |
x86 | x64 | ||
---|---|---|---|---|---|
enc | dec | enc | dec | ||
ULRA | RGBA | 14.902 | 14.130 | 14.700 | 14.558 |
ULRG | RGB24 | 10.594 | 10.230 | 10.977 | 10.586 |
RGB32 | 10.622 | 10.385 | 10.982 | 10.639 | |
ULY2 | YUY2 | 06.713 | 06.470 | 06.919 | 06.821 |
RGB24 | 09.492 | 10.236 | 09.804 | 10.616 | |
RGB32 | 09.235 | 09.683 | 09.535 | 10.045 | |
ULY0 | YV12 | 04.765 | 04.902 | 04.976 | 05.177 |
YUY2 | 05.823 | 06.681 | 05.751 | 06.470 | |
RGB24 | 39.734 | 25.052 | 34.468 | 18.878 | |
RGB32 | 39.825 | 25.235 | 34.567 | 18.847 |
Predict left と Predict median の比較は以下のようになります。
FourCC | 入出力 フォーマット |
フレーム内予測 | x86 | x64 | ||
---|---|---|---|---|---|---|
enc | dec | enc | dec | |||
ULY0 | YV12 | left | 04.765 | 04.902 | 04.976 | 05.177 |
median | 04.844 | 10.680 | 04.922 | 10.674 |
あれ、x64版の方がやっぱり遅い…orz
ULY0 の RGB での入出力がx64版の方が速いのは前回述べたとおりでいいのですが、その他のケースに関しては基本的にx64版の方が少しだけ遅い、という結果になっています。くやしいので、x64版の方が遅くなる理由を考えてみました。
- 64bit 演算を行うと REX プレフィックスが付いて命令が 1 バイト長くなり、命令デコーダの効率が悪くなる。
- このベンチマークは Core 2 で行っている。マクロフュージョンといって、特定の命令ペア(CMP/TEST 命令といくつかの条件分岐命令とのペア)を2クロックではなく1クロックで行えるような仕組みが存在するが、Core 2 ではマクロフュージョンは32bitモード(つまりx86)でしか効かず、64bitモード(つまりx64)では効かない。
こんなあたりでしょうか。ハフマンエンコード/デコードルーチンにおいては、命令レベルの並列性が低いため、前者より後者の方が強く効いているのではないかと思います。実際、x86版のハフマンデコードルーチンでマクロフュージョンが効かなくなる(しかし意味的には等価で命令数も同じになるように)条件分岐に1つ置き換えてみたところ、有意に処理時間が増加していました(ULY2 から YUY2 へのデコードで 0.2ms/frame 程度)。
Nehalem 世代以降では64bitモードでもマクロフュージョンが効くので、こんどこそx64版がx86版とほぼ同じ速度になると思うのですが、持っていないので(8.5.0 が出たら)誰か計測してください(^^;
no comment untill now