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 が出たら)誰か計測してください(^^;

Trackback

no comment untill now

Add your comment now