或るプログラマの一生

前の記事であるUTF-8のコードポイントはどうやってもっと高速に数えるかで AVX2 での高速化をやりましたが、今ではさらにベクタの長い AVX-512 というものがあるので、これでもやってみようかと思います。なお、想定するプロセッサは Skylake-X です。

Qiita に UTF-8のコードポイントはどうやって高速に数えるかという記事がありました。コードを眺めながらもっと速くなるんじゃないのと思ったので、やってみようと思います。

昔 Windows 上での Visual C++ と GCC/Clang の相互運用という記事を書いてましたが、さっき調べたらオリジナルの LLVM （Clang/C2 ではない）を Visual Studio のプラットフォームツールセットとして使うことができて MSVC とちゃんと互換性があるということを知りました。

blog を見ている人には基本的に関係のない話ですが、自鯖（この blog が動いているサーバ）の OS (distro) を CentOS 6 から Ubuntu 18.04 LTS に変更しました。

最近（？）の x86 系パフォーマンスデスクトップ向け製品（Intel ならメモリがトリプル/デュアルチャネルの Core i7 のあたり）のマイクロアーキテクチャ (MA) ごとのキャッシュの構成の一覧。

性能向上

• ULxx: ネイティブな packed フォーマットでの入出力を高速化した。

その他

• ULxx: 「インターレース映像としてエンコード」を非推奨機能とした。
• QuickTime コンポーネントの事実上の廃止にともない、readme から情報を削除した。

前の記事で ULxx の median decode が遅くなると書きました。実際どうなってるのかという話です。

いまさらですが Ut Video Codec Suite のビルド環境を Visual Studio 2017 （というか Visual C++ 2017）に乗り換えようと考えました。 C++17 の機能を使いたかったからなのですが、それはこの記事の本題ではないので省きます。

Ut Video Codec Suite で Halide を使う前提で遊んでみましたが、この前提に立つ限り Halide は使い物にならないように見えます。

Ut Video Codec Suite の最適化をやっていたら、画像処理向けの DSL である Halide を紹介されたので調べていました。 halide とはハロゲン化物の意味なので、読みをカタカナで書くと「ハライド」だと思われます。