或るプログラマの一生

Mac mini を開発機としてセットアップしていました。コーデックの開発にしか使わないので、当面必要になるのは Xcode（必須）と QuickTime 7（厳密にはなくてもいい）です。

Xcode は Lion 用には現在 Xcode 4.2 が App Store に（無料で）あるのですが、ダウンロードしようとすると「使っている Apple ID は iTunes Store で使われたことが無いので登録しろ」という内容の文句を言われます。登録フォームにクレジットカード番号（と iTunes カード番号）の欄があること自体は App “Store” なのだから至極当然なのですが、空にすると登録できません。無料アプリにしか用が無いのに。このクソ林檎が。

性能向上

• 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 コアをまたぐとキャッシュミスして遅くなるので、以下の対策を実装してあります。

Ut Video Codec Suite の Mac 版の開発は、借りている MacBook 上でやっています。そろそろ返してくれということなので、Mac mini (Mid 2011) の梅モデル（= 一番安い 52,800 円のモデルのこと）をヨドバシで買ってきました。

ララビットから限定版が届きました。こっちは PS3 版。２次予約だったので遅れて到着となりました。

バグ修正

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

夜中に始めたら、やめ時を逸したのでそのままエンディングまで行ってしまいました。

まあ、今までのエスコンだと思ってプレイしたらそりゃあコレジャナイってことになりますね。昔々、PC のゲームで戦闘機やら爆撃機やらいろいろ操縦するのをやったのを思い出しましたが、ゲーム全体としてはそれに近いのかもしれません。

エビテン（エンターブレインがやってる通販サイト）から限定版が届きました。箱○版ね。

#534 (Ut Video Support) – FFmpeg

んっ？

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