或るプログラマの一生

以前こういう記事を書いていて、Sandy Bridge を買ったので VMASKMOV 命令に対応させようかと思ったのですが、よくよく命令セットリファレンスを読んでみたら、実際には VMASKMOVPS/VMASKMOVPD 命令で、パックド浮動小数点数用でした。俺はパックド整数を操作したいんじゃー。

リファレンスをさらっと読む限り Ivy Bridge でも実装されなさそうな雰囲気なので、またしばらくお預けのようです（涙

性能向上

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

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

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 で、マルチスレッド化した。

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

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