ロードマップでわかる！当世プロセッサー事情 第125回

CPU黒歴史 真の4コアCPU 初代K10は高消費電力で低性能？

消費電力は高いが性能では
Core 2 Quadに及ばず立場なし

　お題目だけ眺めていると、非常に性能がいいはずのBarcelonaであったが、実際に蓋を開けてみると難しいものになった。確かにコア数の倍増や3次キャッシュの増加により、K8世代の「Athlon 64 X2」と比較した場合は大きく性能を伸ばしていた。だが、当時の競合製品であったConroeベースの「Core 2 Quad」と比較すると、同一周波数では「性能的に肉薄はしているものの、まだ及ばない」という微妙な位置づけであった。この当時は筆者もテストしたが、性能面での総評としては「多分もう少し3次キャッシュが多ければ、大体互角になるんじゃないかな」という感じであった。

　問題は消費電力だ。デュアルコアのAthlon 64 X2より当然増えたのだが、その増え方が尋常ではなかった。2.6GHz駆動で登場予定だった「Phenom 9900」はTDPに140Wを予定していただけでなく、平均消費電力で本当に140Wを使い切ってしまいそうなほどに高い消費電力だった。

　結局2007年9月にまず「クアッドコア Opteron」が発表されるが、この時の動作周波数は1.8GHz～2GHzまで。11月にはデスクトップ向けに「Phenom」が発表されるが、こちらも2.2GHzの「Phenom 9500」と2.3GHzの「Phenom 9600」の2製品のみだった。

　周波数の低い製品しか登場しなかった理由は、既存のSocket F(Opteron用)/Socket AM2＋(Phenom用)マザーボードでは、140Wに達する2.6GHz駆動のハイエンド品では電力供給に不安があるため、マザーボードの更新を待つ必要がある、という凄まじい理由だった。当たり前だがここまで消費電力が上がると、動作周波数を引き上げて性能を上げるのは大変に難しい。結果として、「同一周波数ならばCore 2と結構いい勝負」とは言いながら、動作周波数で差をつけられてしまった。

　これに加えて、BarcelonaのTLBの動作にバグがあることが、2007年末に明らかになったことが追い討ちを掛けた。問題は2次TLBへの書き込みと、2次/3次キャッシュ間の「Modified Copy」が同時に行なわれた場合、TLBの書き込みが一部壊れる可能性があるというものである(必ず壊れるとは限らない)。バグの規模はごく小さいものだが、TLBのデータが壊れるというクリティカルな問題を誘引する危険性がある。対症療法として2次TLBを使わないことが推奨され、ただちにBIOS Updateがマザーボードベンダーから提供された。

　しかし、いくらなんでもこれは性能面へのインパクトが少なくない。結局AMDはただちに、バグのある「Revision B2」に代えてこのバグだけを修正した(つまりほかの対処はほとんど手付かず)「Revision B3」の製造と提供を開始する。だが逆に言えば、これによって性能改善のためのプロセス最適化の機会を逃したとも言える。

　最終的に2008年7月になって、やっと2.6GHz駆動の「Phenom X4 9950 BE」がリリースされるが、TDPは140Wのままであった。「Black Edition」というからには倍率アンロックなのでオーバークロック動作は可能なのだが、水冷キットでも使わないと、とてもじゃないが定格動作がやっとという状況だった。この頃には45nmプロセスでより消費電力が下がったPenrynベースのCore 2 Duoが広く投入されており、45nm版Core 2 Quadも翌2008年8月に投入されたから、まるで勝ち目はなかった。

　もっとも、AMDも対策として次の45nm SOIプロセスの熟成を計り、こちらを利用した「Phenom II」では再び競争力を高めることに成功する。逆に言えばRevision B3のままで終わるなど、初代のPhenomは早いタイミングでAMDからも見切られていたと言える。Phenom IIがリリースされると、初代Phenomは一部の低価格3コア品などを除いて、あっという間にラインナップから消えた。

　TLBのバグは偶発的なものであり、Barcelonaの問題は発熱だった。なぜこんなに発熱が多いのかについて、AMDの65nm SOIプロセスの問題を挙げる人は多いが、筆者はその立場をとらない。というのも、同じ65nmプロセスを使ったAthlon 64 X2やモバイル向けの「Turion 64 X2」では、こうした問題は起きていないからだ。

　では何が問題を引き起こしたのか？　筆者は1次キャッシュとCPUコア間の帯域を、32Byteに広げたことだと考えている。32Byte/サイクルという帯域は、元はと言えばSSEの高速化にともなって、少なくとも1次データキャッシュを32Byte/サイクルにしないと追いつかないところから来ていると思われる。だが1次命令キャッシュで32Byte/サイクルは明らかにオーバースペックで、実際これを使いきれるケースはほとんどない。インテルもSandyBridge世代でようやく32Byte/サイクルを採用したが、これはAVXなどの命令長が長いものに対応するため。Conroe/Penrynの世代は16Byte/サイクルの構造だったし、実際これでほとんど足りていた。

　この32Byte/サイクルの代償は消費電力の増加である。1次キャッシュなので動的な電力制御(クロックゲーティング)の対象にしにくいし、しても常にパワーオンになるからやってもあまり意味がない。バス幅が倍になるわけだから、信号送信の電力も倍増する。しかも一番遅延が少ない部分だから、一番高速なトランジスターを使わざるをえない。これでは消費電力が増えるのも当然である。

　なにより不幸なのは、ここまでやってもあまり性能の改善効果がなかったことだ。1次キャッシュだけが高速という構成は、プリフェッチを注意深く実行して1次キャッシュヒットミスを可能な限り防ぐようにプログラムを書けば、なんとかなるかもしれない。だがこうしたチューニングをしない通常のプログラムでは、アンバランスさがモロに出る。

　そのため一度ヒットミスになるとあとはあまり速くない……。いやはっきり言えば遅い2次/3次キャッシュがボトルネックとなるため、さっぱり性能が出なくなるわけだ。対処は簡単で2次/3次キャッシュも高速にすればいいのだが、恐らくこれをやったら、2コア製品でも消費電力が100Wを超える代物になっただろう。

　そもそもBarcelonaは、K8から小変更だけで32Byte/サイクルを実装することを目的としていた節がある。だから2次/3次キャッシュまで高速にするとなると、Exclusive Cacheの構造にも手をつけないといけなくなり、これはすでに大変更の範疇に入る。

　恐らくAMDとしては、65nm SOIプロセスの素性のよさを見込んで「何とかなる」と判断したのだろうが、見積もりが甘かったのが主要因と思われる。副要因としてはAMDの65nm SOIプロセスがすでに末期であり、開発の主体が45nm SOIに移っていたので、65nm SOIプロセスの改善がもはや見込めなかったことだろう。そして最後のとどめがTLBのバグである。この3つの要因により、Barcelonaは見事に黒歴史入りを成し遂げたと言える。