或るプログラマの一生

その６の続き

今までずっと x86 を試していましたが、 x64 ではどうでしょうか。

機能追加

• ULY2, ULH2, ULY0, ULH0: YV16 での入出力に対応した。

性能向上

• ULY4, ULH4, ULY2, ULH2, ULY0, ULH0: ネイティブな planar フォーマットでの入出力を高速化した。

何をいまさら、と思われるでしょうが、記事タイトルの通りです。

最近 Ut Video Codec Suite の脱アセンブラのために intrinsic への書き換えを進めているのですが、既存の MMX 命令を使ったルーチンを intrinsic に書き換えようとしたらこの問題にぶつかりました。GCC はサポートするようです。

x86 をターゲットにする場合でも、本質的に同じ命令列になるような SSE2 向けのコードと MMX 向けのコードとで最適化の頑張り具合が違う（MMX 向けだと中途半端）という現象が発生しており、その意味でも MMX は推奨されないように見えます。

Ut Video Codec Suite は元々 SSE2 をサポートする CPU 向けであるのに MMX 命令なルーチンがあるのは、書いた当時 (Conroe) は実測したら SSE2 命令で書くより速かったからです。しかし、いろいろ試行錯誤した結果、少なくとも Sandy Bridge だと legacy SSE ではほとんど変わらず、VEX prefixed SSE では有意に速くなるという結果が得られたので、 MMX にはこだわらなくても良さそうです。 Nehalem でどうなるかは気になるところですが。

(This article is English translation of Japanese version. My personal impression is omitted.)

I have benchmarked three latest codecs and one classic codec.

年末だというのに（年末だからか？）コーデックベンチをやっていました。

性能向上

• デコードを劇的に高速化した。

2年半ぐらい前にちょっと実験したもののその後放置していたハフマンデコードの高速化ですが、最近なんかやる気が出て来たので当時やってなかったアセンブラルーチンを書きました。

みっくみく

その５の続き

とてもダメそうな気がしますが、C++ の例外は使えるでしょうか。

その４の続き

C++ だとどうでしょうか。