パフォーマンスへのこだわりは素晴らしいことだね。もしすべてのプロジェクトが同じようにこだわってたら、想像してみてよ。

でも、ちゃんとしたAPI（従来の意味で、SaaSじゃなくて）を持ってたらいいな。自分でプログラミング言語みたいなコマンドラインを理解しなくちゃいけないのはちょっと面倒だよね…。

どこに？あのレッスンにはほとんどコードがないじゃん。

なんで移行するの？

そうだね、x86-64だけだよ。

一般的なCのフォールバックがあると思うけど、それがベースラインにもなるね。でも、大きな（ターゲットの）アーキテクチャには、アーキテクチャごとに手書きのアセンブリバージョンがあるよ。

普通は、vtuneやuprofみたいなツールを使ってISAレベルでベンチマークのホットスポットを分析するよ。ARM用のそんなツールについては全然わからないけど。 > アーキテクチャ特有のアセンブリの代わりに手書きのコンパイラ中間表現（LLVM IR）を書く意味ってあるのかな？私の経験では、あまりないね。手書きのアセンブリを結構やったけど、それはアーキテクチャ特有の問題に対処する時だけだよ。他のことはCで書けばいいし（Cのセマンティクスで表現できないエッジケースに当たることもあるけど、それは稀だし）。例えば、CやC++のコンパイラは、一般的に最適化されたコードを書くのが本当に得意なんだ。彼らが苦手なところは、ベクトル化されたコードみたいに、アルゴリズムを再設計して高速なベクトル命令を使えるようにする必要がある場合で、そうなったらコンパイラのインストリンシックを使わなきゃいけないし、それでもコンパイラのインストリンシックが悪いコード生成につながることもある。だから、結局はアセンブリで書くことになって、レジスタの割り当てやアウトオブオーダー命令みたいなコンパイラが気にすることについて賢くなる必要があるんだ。でも、この領域に入ると、手書きのアセンブリがコンパイラが出力するものより「良い」かどうかを一目で判断するのは無理なんだよね（「良い」の基準は人それぞれだけど）。測定してベンチマークを取らないといけないし、そのベンチマークは意味のあるものでなきゃダメなんだ。

手書きのコンパイラ中間表現（LLVM IRなど）を、アーキテクチャ特有のアセンブリの代わりに書くのは意味があるの？ いや、あんまり。手書きのアセンブリに手を伸ばす理由はいくつかあって、どのケースでもIRは正しい選択じゃないんだ。もしベクターコードを確保するのが目的なら、まずはループに明示的なベクタライズプラグマを付けてみるのが一番の選択肢だよ。それがダメなら、次は汎用またはアーキテクチャ特有のベクターインストリンシックを使うか、SIMT風のベクターコードを書くための言語であるISPCみたいなものに飛びつくことになる。IRに飛びついても、このケースでは特に得るものはないよ。インストリンシックがコードを満たしてくれるからね。もしコンパイラのレジスタ割り当てや命令選択の最適化の問題を回避するのが目的なら… IRで書こうとすると、コンパイラがあなたが書いた正確なシーケンスを元のコードが生成するのと全く同じシーケンスに再正規化する可能性が非常に高くなるよ。コンパイラのIRはコードに何も追加しないし、ただ不安定で使いにくいインターフェースの余分なレイヤーを作るだけなんだ。この場合、手書きのアセンブリのベストバージョンを作るには、結局書きたかったアセンブリをそのまま書くのが一番だよ。

だから、ここでの主な問題は人々が思っているものとは違うんだ。一般的には「最適でないアセンブリ」じゃないし、少なくともCコンパイラから合理的に期待できるものではないよ。要因はこんな感じかな：- 特化：ループの普通のC実装はすでに decent だし、asm/SIMDバージョンは特定のハードウェアプラットフォーム用に追加されている。異なるプラットフォームには異なるSIMD機能があるから、一般化するのは難しい。- 予測可能性：ユーザーは異なるコンパイラのバージョンを使っているから、良いものがあってもみんながそれを使うわけじゃない。- 最適化の難しさ：Cのメモリモデルは特に最適化を難しくするんだ。なぜなら、ビデオは char * で、char * はすべてをエイリアスするから。さらに、コンパイラがこれのために追加する2種類の機能（インストリンシックと自動ベクタ化）はお互いに干渉して、何もないより悪化させることもある。- センス：SIMDを書くためのより良いポータブルな言語を想像できるかもしれないけど、Cはそれじゃない。そして、インテルのCでインストリンシックを使うのもそれじゃない。なぜなら、彼らのものはマイクロソフトによって発明されたもので、何事にも全く美的センスがなかったことで有名だから。アセンブリはCよりも読みやすいよ。だって、全てが _mm_movemask_epi8 みたいな名前の関数呼び出しになるから。

NTAだけど、もし読者がCプログラミングの基本的な理解しか持っていなくて、ビデオコーデックに貢献したいと思っているなら、クーリー/タキーアルゴリズムがどう機能するかを理解するために、かなりのことを学ばなきゃいけないよ。それすら基本的な部分に過ぎないけどね。