こうしたさまざまな性能底上げの策を計ってきた結果、今日ではどうなったか？ まずコア数。最新のRaptor Lakeでは合計24コア、32スレッドの同時実行が可能になっている。ワークステーション向けとかサーバ向けはともかく、コンシューマ向けとしてこれ以上同時実行スレッド数を増やしても、ほとんど性能に寄与するところはない。実際のところ、動画のエンコードとか写真の現像、ゲームをしながら録画をしつつ、ついでに配信も、なんて極端な使い方をしない限り、このコア/スレッド数を使い切るのは容易ではない。では1つのコアで同時処理できる命令数をさらに増やすか？ というと、Raptor Lakeの元になっているAlder LakeのP-Core（高性能コア）の場合、同時デコード命令（x86）数は6、同時発行命令（MicroOp）は17というお化けになっている。そもそもこの同時処理できる命令数に関しては、ポラックの法則（プロセッサの性能はその複雑性の平方根に比例する）が経験的に成立している。複雑性、というのはおおむねプロセッサコアのトランジスタ数、あるいはプロセッサコアの面積としてもよいが、要するに今6命令同時デコードのコアを、仮に7命令同時デコードにした場合、性能は16.7％向上する（7÷6）のに対し、トランジスタ数はおおむね36.1％増える（7²÷6²）計算だ。で、消費電力はおおむねトランジスタ数に比例しがちなので、性能/消費電力比という観点ではむやみに同時処理命令数を増やすのは得策とは言えないし、CPUの物理的な寸法が大型化するのは原価上昇という意味でも好ましくない。

　結局のところ、再び動作周波数を上げるのが早道、という1990年代～2000年代前半のアプローチに戻らざるを得なくなっているのが昨今のプロセッサという訳だ。もちろん、命令の互換性を無視すればいろいろ手はある。古典的な方策ならVLIWが有効だったし、AIプロセッサではデータフローが一時期流行したが、最新のトレンドはCompute-in-Memory（メモリ素子に演算ユニットを融合させる）である。ただこうしたアーキテクチャでx86との互換性を取るのは難しい。なにより、こうした最新のアーキテクチャではIPC（Instructions Per Cycle：1サイクルに処理できる命令数）ではなくDPC（Data Per Cycle：1サイクルに処理できるデータ数）を重視しており、必ずしも古典的なプログラム（Office SuiteとかWebブラウザとかはその典型例だろう）には適していない。製品競争力を上げるためには性能を引き上げざるを得ず、そのためには動作周波数を上げるしかない、というのが昨今の状況という訳だ。

　写真7はやはりRaptor Lakeの説明の中で出てきたものである。第12世代CoreであるAlder Lakeを241ワットで駆動させているときの性能と、Raptor Lakeを65ワットで駆動させているときの性能はほぼ同等だ、としている。にも拘わらず、実際にはRaptor Lakeは最大253ワットで駆動するような構成になっている。実に消費電力は3.8倍にもなっているにもかかわらず、性能の増分は僅かに41％でしかない事を考えると、筆者なら65W構成で出荷したくなるのだが、それは許されなかった訳だ。かつてはオレゴンと異なり、低消費電力路線を追求していたIDCからこういう製品が登場するあたりに、いろいろ考えさせられる発表であった。

写真7　後追いで65Wの製品も登場という話なので、性能/消費電力比を重視する顧客は来年以降になると思われるこうした低消費電力のラインアップが出そろうのを待つのが吉だろう