何をいまさら、と思われるでしょうが、記事タイトルの通りです。
最近 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.
Read the rest of this entry
年末だというのに（年末だからか？）コーデックベンチをやっていました。
Read the rest of this entry
- 性能向上
-
Read the rest of this entry
2年半ぐらい前にちょっと実験したもののその後放置していたハフマンデコードの高速化ですが、最近なんかやる気が出て来たので当時やってなかったアセンブラルーチンを書きました。
Read the rest of this entry
その５の続き
とてもダメそうな気がしますが、C++ の例外は使えるでしょうか。
Read the rest of this entry
その４の続き
C++ だとどうでしょうか。
Read the rest of this entry
その３の続き
その３ではリンクを Visual C++ 側で行いましたが、GCC 側でも行ってみます。
Read the rest of this entry
朝起きたら ARM 版 Windows 10 が発表されてました。Windows RT とは違ってフル機能の Windows 10 が動くらしいです。ネイティブ環境としては ARM64。しかも x86 エミュレーションあり。お兄さんビックリです。さすがに？ x64 エミュレーションは無いようですが。
フル機能の Windows 10 が動くということは、マルチメディアフレームワークである Video for Windows や DirectShow も当然載っていることが期待されます。そうするとコーデック開発勢としては ARM のアセンブラを勉強しなきゃいけないんですが、手持ちの ARM デバイスは Nexus5 しかなくて、これだと Java から呼び出すことになってしまって面倒です。母親の iPhone 6s を使うという手もありますが、これもこれで面倒です。
世の中には Raspberry Pi というものがあり、 Linux が普通に動いて（クロス開発ではなく）ホスト開発できてしまうので、これを使うのが良さそうです。Raspberry Pi 3 なら ARMv8 なので 64bit 開発可能です。これ本体ボードだけなら5000円しないんですね。安いなぁ。
ところで、発表されたので ARM の技術情報を見に ARM のサイトに行ったんですが、サーバが重いせいか昼からずっとアクセスできません。元から重いのか Windows の発表のせいなのかは分かりませんが…