いまさらですが Ut Video Codec Suite のビルド環境を Visual Studio 2017 （というか Visual C++ 2017）に乗り換えようと考えました。 C++17 の機能を使いたかったからなのですが、それはこの記事の本題ではないので省きます。
とりあえず乗り換える際にはベンチマークを取るわけですが、計測してみると ULxx の predict median のデコードと、UMxx のデコードが遅くなります（その他のケースは計測誤差程度）。Haswell の場合は両方とも 1% 程度なのでコンパイラの新機能と引き換えに目をつぶるとしても、Sandy Bridge の場合 UMxx の方で 10% も遅くなっています。さすがにこれは無視できません。VS2017 だと最適化性能が弱くなったのかと思って ICC (Intel Compilter) で Sandy Bridge 向けに最適化する設定でビルドしてみたところ、 VS2017 よりは速いですが全体的な傾向は変わりません。プロジェクト全体は VS2017 でビルドしつつ SIMD ルーチンのソースファイル (TunedFunc_x86x64_avx1.cpp) は VS2015 でビルドしたものを持ってきてリンクさせると全体を VS2015 でビルドしたのと同じ速さになるので、SIMD 周りの最適化の問題であることは分かりますが、分かったところで何の解決にもなりません。ちなみに VS2019 preview で試してみてもやっぱり同じです。
つまり当該コードに関しては Visual C++ 2015 が最も性能の高いバイナリを吐くということになります。VS2017 と比較して速いだけならともかく ICC にすら勝っているというのは俄かには信じられませんが、バッチリ再現性があるんですよね…
なお、短期的には C++17 の機能は（そこまで強く使いたかったわけではないので）諦めて、Ice Lake が出た段階で VS2019 に移行しつつ Sandy Bridge は推奨環境から外れる、ということにしようと思っています。
この記事とそのコメント欄のリンク先にある話と同じ問題かもですね・・・。
rigayaの日記兼メモ帳 謎が深い…
https://rigaya34589.blog.fc2.com/blog-entry-990.html
新しい命令セットだと最適化がこなれてないのは良くあることですが対応してからだいぶたってるし、不正な命令が出てきたりするわけでもないので話が違いそうです。
覚悟を決めて（？）バイナリを目で見たらやっぱり VS2017 は最適化能力が落ちていて、ただ落ちているのはベクトル化部分ではなく汎用レジスタ処理のようです。ふええ…
VS2017 (VC++2017) の最適化が 2015 より弱い例
前の記事で ULxx の median decode が遅くなると書きました。実際どうなってるのかという話です。 gradient/left の decode は遅くなっていないので、怪しいのは tuned_RestoreCylindricalWrongMedian8 ということになります。最後の for ループの部分は以下のようになっています。 for (; p < pSrcEnd; p++, q++) { __m128i top = _mm_cvtsi32_si128(*(const uint3…