或るプログラマの一生

Ut Video Codec Suite のインストーラを置き換えるべく、Inno Setup と格闘しています。これを書いている時点では格闘はおおむね終わっているのですが。

@nowarashi / ののの さん曰く、

当たり前っちゃ当たり前なんだけど、ニコニコサービス外のものには親子関係できないから、配布動画はなくてコミュニティにモデルのURL書いてあります、とか言う人は、ニコニコ静画にスクショ一枚上げとくと良いかも。

http://twitter.com/nowarashi/status/146485165991006209

性能向上

• Mac で、Windows 版と同程度にアセンブラ化した。

デコーダを実装したので次はエンコーダなのですが、「AVI ファイルに対応した」エンコーダを書く方法が分かりません。

性能向上

• Mac で、マルチスレッド化した。

一晩おいて思ったんですが、前回の記事での測定結果は一部直感に反するのですよね。

• SetThreadAffinityMask 等を呼ばない場合に速くなったり遅くなったりするのは、直感に合致する。たまたま別のコアにスレッドが割り当てられたら速くなるだろうし、同じコアの別の論理プロセッサに割り当てられたら遅くなるだろう。
• SetThreadIdealProcessor を呼んだ場合に（速くはならないが）遅くならないのは、直感に反する。しかも、測定時はわざと同じコアの別の論理プロセッサを優先的に使うように指示したにもかかわらず、遅くなっていない。
• job queue をスレッドごとに持たなくても速度に変化が見られない点については、よく分からない。直感ではどちらとも言いがたい。

あと、測定したのは i7-2600K SandyBridge 上なのですが、この CPU の LLC は（わずかに non-uniform access だけれども）共有なので、スレッドがコアを移動することによるペナルティは比較的小さいはずです。そのため前回の測定結果では差が見られないという可能性があります。たとえば Core 2 Quad とかだと L2 はダイごとに分かれていて、しかもダイ間は FSB という今時ものすごく遅いバスを介して接続されているので、ペナルティは相対的に大きく出るでしょう。すぐに計測できればいいんですが、今環境が無いので…（マザーやCPUはある）

というわけで、もっと詳細な計測ができるまでは、Win32 に関してはこのままにしておきます。pthread の場合は完全に新規に書くことになるので、もっとも単純な構造にします。

Ut Video Codec Suite はマルチスレッドエンコード/デコードをサポートしています。ULxx においてはスレッドへの分割は映像を横長の帯（これを band といいます）に分割して割り当てるのですが、分割後の処理中にスレッドが CPU コアをまたぐとキャッシュミスして遅くなるので、以下の対策を実装してあります。

バグ修正

• Windows で、入出力の幅と高さが一致していることをチェックしていない。

#534 (Ut Video Support) – FFmpeg

んっ？

注： wishlist が登録されただけであってコードが commit されたわけではない（少なくとも現時点では）

いつでも QuickTime の挙動調査。今回はちょっとだけ。