ついに対応した64bitモードに弱点あり
ここまでの結果はCore 2の圧勝だったが、実は意外なところに弱点があった。64bitである。
といっても、64bitのWindows XP上で今回テストしたようなプログラムを走らせる場合には、目立った性能の変化はない（これはAthlon 64でも同じ）。問題は、64bit Windows用にコンパイルされた、いわゆる64bitネイティブアプリだ。
とくに、ほぼ同機能のアプリが提供されている「Panorama Factory」（複数の画像をつなげて360度の写真を作るソフト）や「sakura editor」（テキストエディタ）、「7-Zip」（高性能圧縮ソフト）の結果を見ると事態がよく把握できる（グラフ15～17）。Athlon 64はいずれも64bitネイティブ版のほうが性能がアップしているのに対し、Core 2 Duoはよくて横ばい、場合によっては40％も、ネイティブアプリのほうが低速になっている。その結果、「7-Zip」では32bitだとCore 2-2.4GHz程度の速度だったFX-62が、64bitだとCore 2-2.93GHzに迫る数値になり、「Panorama Factory」でも、Core 2-2.4GHzはFX-62に抜かれ、「sakura editor」に至っては、32bitではラスだったFX-62が一気に逆転トップを飾っている。
 |
|---|
| グラフ15 棒が短いほど高速。64bit対応アプリとしてはもっとも早期に登場した「Panorama Factory」で、6枚の画像を360度のパノラマ画像に変換するのに要した時間。Athlon 64では64bit版を使ったほうがぐんと高速化するのに対し、Core 2では逆に大幅な速度ダウンが見られる |
 |
|---|
| グラフ16 棒が短いほど高速。エディタソフト「sakura editor」で、526000回の置換を行なうのに要した時間。ここではCore 2における速度低下が著しく、64bit版についてはFX-62がトップの成績を収めた |
 |
|---|
| グラフ17 棒が短いほど高速。高性能圧縮ソフト「7-Zip」による圧縮時間。Athlon 64ではいくらかスピードアップしたが、Core 2ではほとんど性能が上がっていない |
原因はおそらく、Core 2のアグレッシブな設計と、64bit対応への着手の遅れだろう。
すでに述べたように、Core 2は1クロックにつき最大5命令を命令キャッシュから取り出し、解析することができる。しかし、この際のデータバスは20バイトとなっている。5命令取り込むためには、1命令あたり平均4バイト以下である必要がある。x86の命令は典型的な例だと、レジスタ間での演算で2バイト、メモリアクセスが2～4バイト、サブルーチンコールが5バイト、条件分岐で2～6バイト、オペランドに32ビットの数値をダイレクトに参照すると、プラス4バイト必要といった具合で、処理によってかなりばらつく。それでも平均4バイトというのはそんなに無茶な設定ではないように思われる。
しかし、64bitのネイティブアプリにおいては、レジスタを「64bitレジスタとして使う」場合、あるいは「64bitで拡張されたR8～R15、XMM8～XMM15などのレジスタを使う」場合に、命令の途中に“REX”という拡張符号（プリフィクス）が追加される。64bitネイティブアプリの高速化の大きなポイントは、この拡張レジスタを使用する点にあるため、これが出てくる頻度はきわめて高いと考えられる。5つの命令中、仮に4つでこれが出てくると、それだけで命令長は4バイト増えてしまう。これによって、32bitモードでは1クロックにつき5命令取り込めたのに、64bitモードでは4つ以下しか取り込めない、という事態も発生するだろう。
64bit版Vistaへの影響が気がかり、フォローの余地はあるか？
最初から64bitを前提に設計していればよかったのだろうが、Core 2の源流とも言うべきPentium M（Banias）のコアは、もともとモバイル向けだ。消費電力削減に精力を傾ける一方で、「4GBオーバーのメモリの搭載」は用途として想定しておらず、64bit対応へのインセンティブが低かったのではないか。実際、64bitのWindows XPは2年以上も前からβテストが始まり、昨年春には正式版も発売されているのに、今年1月に登場した（Pentium M後継の）Core Duoは64bitに対応していなかったことからも、64bit対応にとりかかったのが比較的最近であることを伺わせる。
もっとも「VirtualDub 64」上での64bit「Xvid」による圧縮とか、「Shade 8.5」によるレンダリング、といった64ビットアプリでの処理においては、Core 2-2.4GHzでもFX-62を上回るスコアを出している（グラフ18、19）。Shadeにおいては、64bit版のほうが若干高速になってもいる。Athlon 64だと劇的に高速化しているのに比べると、相当な逆風を受けていることは確かだが、おそらくはSSE命令を多用するプログラムだけに、SSEのスループット向上効果でリカバーできたのだろう。いずれにしろ「sakura editor」を例外とすると、64bit環境ならAthlon 64系のほうが高速、と言えるほどではない。
 |
|---|
| グラフ18 棒が短いほど高速。64bitの動画編集ソフト「VirtualDub64」上で、64bit対応のCODEC「Xvid64」を使ってファイルを圧縮する際の時間。これはCore 2が高速だ |
 |
|---|
| グラフ19 棒が短いほど高速。64bit対応のCGレンダリングソフト「Shade 8.5」に付属のベンチマーク用データ“rex”のレンダリング時間。Athlon 64では64bit版を使うことで大幅な速度向上が見られるが、Core 2ではごくわずかな差しかない。とはいえ、速度的にはCore 2のほうが上回っている |
ただ、Vistaのラインナップのほとんどすべてに64bit版が用意され、来年はいよいよ64bitがデフォルトになろうかという勢いなのに、「64bitアプリのほうが遅いことが多々ある」というのでは意気阻喪してしまう。「メモリを4GB以上積む必要にも迫られていないし、デバイスドライバやアプリの互換性にも不安があるし、まして、遅くなるんだったら、64bit OSを使う必要はない」と考える人が増えると、OSの64bit化への流れにも水を差すことにもなりかねない。実際困らないのなら何も64bit OSを使う必要はないともいえるが、ソフトとハードは車の両輪として、互いに刺激し合いながら進化していくものだ。ソフト環境の一大ステップアップにブレーキがかかるのは、PCの世界全体にとってマイナスだろう。
CPUの設計をそう簡単に変えることはできないだろうから、残る期待はコンパイラのCore 2向け最適化と、ソフトハウスの再コンパイルということになる。まあ、そもそもCore 2ではSSE4命令（という名前かどうかは不明だが、ベンチマークセッション時の取材によると、エンコード時のメモリアクセスを高速化するなどの拡張命令を含むという）も追加されているし、マルチメディア処理ルーチンにおいては、SSE命令のスループットが1になってもいるため、最適性能を達成したければアプリの微調整と再コンパイルはどうせ必要なのかもしれない。また、幸いまだ64bitアプリの数はごく少ない。今ならまだソフトは出荷前にCore 2対応を施すことも可能というタイミングかもしれない。
Core 2で64bit Windowsを使う場合には、使いたいアプリの32bit版と64bit版のどちらがより高性能か知りたくなるだろう。いちいち調べるのは面倒ではあるが、Core 2の導入でそのくらいの手間を補ってもはるかに余りある高性能・低消費電力マシンが実現できるのは確かだ。昨年、デュアルコアCPUの登場によって、マルチスレッドアプリは画期的な性能向上を享受するようになったが、これはまあ、CPUが2個入っているんだから当然、という面があった。それに比べると、Core 2による性能のブレイクは、久しぶりに“設計が持つ力”を見せてくれた。
【関連記事】
