最近、イライラすることが。Apple Wireless Keyboardに、抜け落ちたまつ毛が入り込んでしまったんですよ! エアダスターをぶしゅっと吹きかけると事態はさらに悪化、裏側のロゴ付近に到達して"病膏肓に入る"状態に。ああ、バラすのが面倒くさい。

さて、今回も前回に続きIntel Macについて。この一週間、いろいろなコーデックをベストパフォーマンスで利用すべくテストを続けてきたので、その報告がてらIntel Macを取り巻くオープンソースソフトウェアの状況などをお伝えしてみよう。

アセンブラ周りは鬼門

高品質なMP3ストリームの生成で知られる「lame」、MPEG-1/2など各種コーデックに対応する「ffmpeg」など、オープンソースで開発されているエンコーダの多くは、MMXやSSEなどx86に最適化するためのコードを含んでいる。通常はCPUに依存する命令(アセンブリ言語)で記述されているので、これまでPowerPCを利用してきたOS Xユーザには関係のない話だったが、Intel Macではその恩恵を受けられる……はずなのだが、そうは問屋が卸さなかった。

先週も少し触れたが、問題はnasm(Netwide Assembler)というx86 CPU用のアセンブラと、生成したオブジェクトを結合させるリンカだ。Intel MacにXcode Toolsを導入すると、gccやmakeなどGNU製のコンパイルツールとともに、nasmもインストールされるのだが、どうやらそのままでは利用できない。Xcode Toolsに含まれるリンカ(ld) はApple製で、多くのオープンソースソフトがライブラリの生成に用いるGNU libtoolではうまく扱えないことが多いのだ。

実際、最適化オプションを付けずにconfigureスクリプトを実行すると難なくビルドできるlame v3.97b2も、「--enable-nasm」を有効にしてビルドしようとしたところ、nasmを実行する箇所でコケてしまった。ffmpegもMMXを有効にすると×。後ほど紹介するH.264/AVCエンコーダの「x264」も同様に、nasmを実行する箇所でエラーとなる。少し調べたところ、configureスクリプト中の実行環境を判定する箇所で、nasmで生成するフォーマットをMach-OにすべきところがELFを指定してしまうなど、ホスト情報(i686-apple-darwin8.4.1) を与件とした分岐処理がうまく行われていないものも見受けられた。

この辺りは、基本的にconfigure.inの書き換えなど開発側の対応を待つほかないが、Xcode Toolsに付属のnasm(/usr/bin/nasm)にも問題がある模様。というのも、nasmのCVS版コードを自力でビルド、/usr/local/binへインストールしたものを使用したところ、x264のビルドに成功したからだ。

x264でPower Macと比較する

今回使用したx264のソースコードは、1月25日付の最新版。それをPower Mac G5(PPC 2.0GHz×2/RAM 2.5GB)とIntel iMac(Core Duo 1.83GHz/RAM 512MB)でコンパイル、YUV 4:2:0のRAWファイル(約3分30秒/840MB)をソースとしてエンコードにする時間を測定してみた。

結論からいうと、Intel iMacの圧勝。最適化命令が有効な状態ではPower Mac G5より約160%高速、逆に無効時には約30%低速という結果からは、MMXやSSEなど拡張命令セットの効果のほどが伺える。

拡張命令セットに対応するlameやffmpegなどオープンソースのエンコーダをIntel Macでビルドできるようになれば、動画や音楽のエンコード環境が確実にパワーアップするはず。iPod用ムービーをサクッとエンコードできる日は、もうそこまで来ている……のかもしれない。

Intel iMacとPower Mac G5のx264エンコード性能比較

	Intel iMac	Power Mac G5
x264がサポートするそれぞれの命令セット	MMX/MMXEXT/SSE/SSE2	Altivec
最適化有効	2分34秒73	4分11秒73
最適化無効	10分36秒66	8分07秒08

※: 使用したコマンドラインは「x264 -q 20 -B 700 -b 1 --direct spatial --threads 4 -o out.x264 VIDEO.YUV 320x240」。最適化無効時には、そこへ「--no-asm」オプションを加えた