或るプログラマの一生

前の記事の通り、アセンブルは正常に完了するようになったのですが、今度はちゃんとリンクできません。

Xcode は（というか Mac OS X が、か？）ツールセットが gcc / llvm なのでアセンブラとして gas が使えますが、もう 1 つ NASM も標準で入っていて、好きなほうを使うことができます。

ところがこの NASM、入っているバージョンが「古い」です。

Ut Video Codec Suite の Mac 版におけるアセンブラ化の一環として、MASM から NASM への書き換えを行っています。Mac で MASM は使えないためなのですが、GAS に移植して2バージョンメンテするのではなく、NASM に移植して1つのソースから Visual C++ 用と gcc 用の両方を生成すべきでしょう。

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

機能追加

• URIInfo::Twitter で、ツイート以外の URL や https にも対応した。

その他

• Google 電卓の挙動の変化にまた追従した。
• Content-Encoding を正しく解釈するようにした。
• 文字エンコーディングの推測精度を改善した。

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

バグ修正

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