ゴールデンウィークが近づいていますが、皆さんの予定はいかがですか? 私は、混雑すること確実な観光地は避け、空いているはずの都心をうろつこうと考えています。果たして銀座のアップルストアは混雑するでしょうか?

さて、今回は新Mac Proについて。最高でクアッドコアのIntel Xeon(Clovertown)を2基、しめて8つのコアを搭載できる噂のモンスターマシンだ。一昨日筆者の書斎に到着、目下試験運用中なわけだが、レビュー記事にまとめるには少々ニッチなネタが集まってしまったため、当コラムで先行して紹介してみることにした。

コアが8つということ

8コアMac Proの第一印象は、速いというより"静か"。8コアをフル回転させるアプリケーションは、現在のところ数が少なく、Webのブラウジングやメールの読み書きといった軽作業はもちろん、iTunesやQuickTimeを利用した音楽 / 動画のエンコードもラクラクこなす印象。内蔵のファンが騒がしいということもなく、使用感は軽やかだ。

本当にコアが8つもあると実感するのは、システム環境設定の「Processor」ペインを開いたとき。CPU1からCPU8までチェックボックスが並ぶ様は、壮観というより笑ってしまうほどだ。なお、ProcessorペインはXcode Toolsに含まれる「CHUD」を選択(初期設定ではインストールの対象外)する必要があるので、念のため。

メガマック"なみにパワー過剰な「8コアMac Pro」

CPU欄にスクロールバーが表示されている「Processor」ペイン

テスト1: iTunes 7 vs ノーマルLame

早速MP3のエンコードテストに移ろう。使用するアプリケションはiTunes 7.0.2とLame 3.97、フォーマットにはMP3を使用した。設定条件をできるだけ近づけるため、iTunesの設定には下図を、Lameではコマンド実行時のオプションに「-V2」(--preset standardと同じ)を指定した。Lameをコンパイルするときには、最適化等のオプションは何も指定していない。なお、テストに使用した楽曲(AIFFファイル)は約71MB、再生時間は7:01分というもの。

iTunes 7のエンコード設定

結果はiTunes 7が5.5秒、Lame 3.97が27.8秒と、iTunes 7の圧勝。理由はiTunesにビルトインされたMP3エンコーダのアルゴリズムにもあるはずだが、マルチスレッド化されているかどうかも影響していると考えられる。試しにアクティビティモニタで確認したところ、iTunes 7でエンコード中はスレッド数が11～12にまで増加するが、Lameは終始スレッドが1のまま。これでは8コアの実力が活かされないため、少々工夫する必要がありそうだ。

LameとiTunes 7のスレッド数の違いに注目

テスト2: Lameを最適化

テスト1では、Lameをコンパイルするとき最適化をまったく考慮しなかったため、XeonのSSE拡張命令を有効にするための最適化オプションをいくつか指定した。その結果だが、27.1秒と最適化前とほぼ変わらず、またしても8コアの実力を測り損ねてしまった。

テスト3: Lameをマルチスレッド化……のはずが

LameがiTunes 7に比べて遅い理由の1つは、マルチスレッド化されていないことにあるのだから、手っ取り早く対応させる方法は……と探したところ、「The LAME MT Project」を発見。以下の要領でビルドを行い、テスト1 / 2と同条件でエンコードを行った。調べたところ、Linuxではマルチスレッド化に成功、デュアルコアマシンでは30%ほど高速化(VBRエンコード時)されるようなので、うまく事が運べばOS Xでも、という寸法だ。

その結果は……惨敗。テスト1 / 2より遅い29.7秒となってしまった。残念ながら今回は対処方法を見つけることはできなかったが、Lameにかぎらずアプリケーションのマルチスレッド化はマルチコア環境を活かす鍵となるはずなので、今後注意して見守りたいと思う。