さらばIPC(CPUの性能指標を考える。)   

2004年1月5日



新年あけましておめでとうございます。

年頭挨拶である初夢コラムを除くと、本記事が事実上今年の最初のコラムとなる。 本年も駄文におつきあいいただきたい。

おめでたいことに年明け早々10万アクセスを達成できたようだ。 1万アクセスからほぼ1年で10倍のアクセスを達成できた事になる。 ホラ吹き野郎が放言を吐くだけのウソ八百サイトがなぜ10万アクセスを 達成できたのか本人としては不思議で仕方がないのであるが、 こんなへっぽこサイトの記事でも読んでいただけるとは大変ありがたいことである。

というわけで10万アクセスありがとうございます。

☆パソコンと米びつの類似性???   
さて、1/3まで実家に帰省していた訳だが、 実家に帰ると母親からあれこれ頼み事をされるのが面倒だ。 まあ、面倒ながら親孝行だと思ってやっているわけだが...

以前にもこんな事があった。 (ホントは名古屋弁の会話なんだけど、愛知県人以外には解読不能の暗号と化す ので標準語モードにしてある。 たるさんは実家に帰ると3秒で名古屋弁モードに切り替わるのだ。)

母:「あんたパソコンばっかりいじってちゃダメだよ。 ちゃんと仕事しないと...」

たるさん:「パソコンばっかりいじってちゃダメだよなんて言うけど、 オレ、壊れたコンピュータとか修理して会社でも少しは感謝されてんの!」

母:「あんた、パソコンを修理できるの?」

たるさん:「測定器のコンピュータを修理した事がある。特殊な装置だから 浮いた経費も普通のパソコンとは比較にならないハズ。」

母:「じゃあ、あんな機械を直すのは得意なんだね〜。ちょうど良かった。 直して貰いたいのがあるんだけど...」

たるさん:「あぁ、わかったよ。何が壊れたの?」

パソコンかビデオでも壊れたんだろか?と思いつつ、母親についていくと そこは台所。ん、壊れたのはオーブンレンジ? なんて考えていたオレが甘かった。

「こっち、こっち。」と母親が指し示したのは、なんと ボタンを押すとお米が一合出てくる米びつ。

ちょっとちょっと〜。 母の頭の中では、パソコンとお米が一合出てくる米びつは 同じ種類の機械なのかい???

たるさんは全身からがっくりと力が抜けて「はぁ〜。」とため息。 頭がクラクラする。

パソコンとビデオを同種の機械と考えるなら、同じ電化製品だから まだわからんでもない。 でも、パソコンと米びつが同じ種類の機械に分類されるとは!  どう考えても同種の機械ではない。 そもそも、米びつはコンセントも付いていないから、電化製品ですらないぞ。

こんな機械音痴の遺伝子を受け継いでいるから、いつまで経っても たるさんは「窓際技術者」から抜け出せないんだろうな〜。

☆高クロックと高IPCはどちらも同じ寄与。   
さて、当サイトではCPUアーキテクチャ等についていろいろと考えているのであるが、 アマチュアの限界というか、本人がタコだというか、母親の遺伝子のせい なのか、それは分からないが、何を指標に性能を把握すればいいのか悩むことがある。

ベンチマークは直接的指標だが、これはあくまで性能をある一面から数値化したもの に過ぎない。CPU間の優劣を比較するには良いが、 内部構造の善し悪しについて直接問題点を指摘してくれるわけではない。 アーキテクチャの善し悪しを考える際にはベンチマークと共に、 頭の中で構造を考える際の助けになる「概念的性能指標」が必要なのである。

この概念的性能指標であるが、PC雑誌でよく取り上げられるのは 「クロック周波数×IPC」という指標である。 クロック周波数とIPCの積が大きいほど優れたアーキテクチャであると言うのだ。

よく比較されるのがQuantiSpeedアーキテクチャ(AthlonXPのアーキテクチャ)と Net-Burstアーキテクチャ(Pentium4のアーキテクチャ)である。 QuantiSpeedアーキテクチャは高IPCの代表格として、 Net-Burstアーキテクチャは 高クロック周波数の代表格として語られる事が多いようだ。

ここで、性能指標である「クロック周波数×IPC」を見ると、IPCとクロックが 同格の扱いであることに気が付く。例えば、この式が 「クロック周波数×logIPC」とか、 「クロック周波数1/2×IPC」とかだったらどうだろう。 前者ならクロック周波数さえ高ければよく、後者ならIPCを高めた方が効果的だ。

何が言いたいかというと、「クロック周波数」と「IPC」は まったくの同等であるということだ。 どちらの手法が優れているというわけではなく、 どちらで性能を高めるかはアーキテクトの設計思想次第なのである。

PCマニアの間では高IPC路線がエレガントと考えられているようで、 高クロック路線は力技として嫌われる傾向が強い。 実際の所、ベンチマーク結果はほとんど互角なのに、QuantiSpeedアーキテクチャを 誉める人は多いが、Net-Burstアーキテクチャを誉める人はほとんどいないのである。

Net-Burstアーキテクチャが高IPC路線で設計されたアーキテクチャであり、 「設計通りに行かず低IPCなのでやむなく高クロックに走った。」 というのであれば批判は当たっているであろう。 しかし、Net-Burstアーキテクチャは設計当初からP6アーキテクチャより 低IPCであることを承知の上で設計されたCPUであり、 この批判は当てはまらない。

少し位低IPCとなってもそれ以上に高クロック化できれば総合性能は上がる という設計方針で設計されたアーキテクチャなので、 Pentium4のクロック周波数は常にAthlonXPの実クロックを上回ってきた。 つまり、低IPCを承知の上で、それ以上にクロックを高める自信があったからこそ 採用されたアーキテクチャだし、実際その通りの経緯をたどったのである。

たるさんがPC雑誌で少々不満なのは「クロック周波数当たりの性能」という ベンチマークの同一周波数換算値がよく発表されることだ。 これはIPCの優劣を比較するためにはやむを得ない事ではあるのだが、 これだけでアーキテクチャの優劣を判断するのは明らかに間違いである。 「クロック周波数」と「IPC」が同格である以上、 一方だけを評価するのは間違いなのだ。

もし、「クロック周波数当たりの性能」を比較するのなら、 「同一時期のフラッグシップ同士の最高周波数比率」も掲載するべきで、 そうしないと二つの指標の内、一方だけで判断を強いられる事になる。 下表を見れば分かる通り、「クロック周波数当たりの性能」が2倍優れていても、 「同一時期のフラッグシップ同士の最高周波数比率」が半分ならば、 総合性能は五分と五分である。 Pentium4の実クロック周波数が常にAthlonXPの実クロック周波数を 上回ってきたのはアーキテクチャ上の理由があってのことなのである。

クロックサイクル 高クロック動作 高IPC動作
命令1 命令1 命令2
命令2
命令3 命令3 命令4
命令4
命令5 命令5 命令6
命令6
IPC 1命令/サイクル 2命令/サイクル
クロックサイクル 1クロック/サイクル 2クロック/サイクル
実実行時間 6クロック 6クロック

注意:命令の実行には実際にはパイプライン段数分のサイクル数が必要である。
しかし、連続命令実行中の一部と考えて、 スループットのみで評価した。
レイテンシは無視する方が実際的である。

☆高IPCとは何だろう?   
というわけで、お正月休みはこの二つの指標についてゆっくり考えてみようと思った。 CPUアーキテクチャについて考える事が趣味で始めたサイトなので、 そのレベルを「ヘタの横好き」から「PCマニア」のレベルまで高めるため、 その判断の根底をもう一度しっかりとおさらいしてみようと思ったのである。

まず、高クロックは問題ないだろう。 だって、クロック周波数は実際に測定できる値だし、 アーキテクチャが同じならば高クロックほど 演算性能が高いのは疑いようもない事実なんだしね。

ところが問題なのは高IPCだ。 今までたるさんもPC雑誌もマニアも「高IPC=高性能」説を疑っていなかった。 クロック周波数が同じならば、高IPCほど高性能だと考えてきたのである。

しかし、まじめに考えれば考えるほどこれは不思議な指標だ。 だって、そうでしょう?

まず、第一に高IPCと言った場合、各アーキテクチャでは内部命令 (Net-BurstアーキテクチャならμOPs、QuantiSpeedアーキテクチャならMacroOps) を基準に考える場合が多い。例えばNet-Burstアーキテクチャの場合、 演算リソースの使用率はHT無しの場合で35%であると公開されているが、 これはμOPsで35%であって、x86命令で35%ではない。 なぜならば、内部RISC型であるPentium4はμOPsしか実行できないからである。 (x86命令が実行できるのは、あくまで見かけ上の話である。)

そうすると、例えば同じ1x86命令/サイクルでも、Pentium4とAthlonXPでは 比較できなくなってしまう。なぜならば、同じx86命令を実行していても 実際に実行される内部命令が違う物である以上、同じIPCでも 性能は違ってしまうからだ。

例えば、あるx86命令をAthlonXPは2つのMacroOpsに、 Pentium4では3つのμOPsに分解していると仮定しよう。 これらがどちらも並列実行できないと仮定し、また動作クロックは同じと仮定すると、 AthlonXPのIPCは1MacroOps/サイクル。Pentium4もIPCは1μOPs/サイクルである。 見かけ上IPCは同じである。

サイクル数 AthlonXP Pentium4
サイクル1 命令1 命令1
サイクル2 命令2 命令2
サイクル3 処理終了 命令3
IPC 1命令/サイクル 1命令/サイクル
実実行時間 2サイクル 3サイクル

注意:あくまでもたとえ話である。
実際にこうだと言っているわけでは無いので注意。

しかし、実行時間はAthlonXPは2サイクルで、Pentium4では3サイクルである。 (注意:これはあくまでたとえ話で、実際にこうだと言っている訳ではない。) つまり、同じIPCで同じクロック周波数なのに、 実際の性能が違うという矛盾が発生してしまうのである。 両者の内部命令セットに違いがある以上、内部命令の働き具合にも違いがあり、 両者のIPCを同列に比較することはできないのだ。 (内部命令の命令セットが巧く作り込まれているかどうかが 性能差につながるわけである。)

☆命令セットが同じでも...   
では内部命令ではなく、見かけ上の実行命令であるx86命令で比較すればどうだろう。 x86命令ならば両者共に同じ命令セットなんだから比較できるのでは? なんて思ったので考えてみた。

先ほどの例で言うとAthlonXPは1つのx86命令を2サイクルかけて実行し、 Pentium4では3サイクルかけて実行しているのだから、 x86命令を基準としたIPCは、AthlonXPでは1/2x86命令/サイクル、 Pentium4では1/3x86命令/サイクルとなる。 同クロックならばAthlonXPの方が速い事を意味する数値になったわけで、 この方法ならば一見正しいように思われる。

しかしだ...よくよく考えてみるとこの方法でもダメだ。

いい例がEfficeonである。 EfficeonではCMSが動的に命令の消尽を行ったり、複数のx86命令を 効率の良いatom1個で置き換えたりする。

こうなるともうわけがわからない。 例えば2個のx86命令があったとする。 これをEfficeonでそれぞれ2つのatomに置き換えると仮定しよう。 そして、合計4atomの内2atomをCMSが動的に消尽できるとしよう。 つまり、実実行atom数は2atomだ。

そうなるとどうだろうか?

EfficeonではCMSオ−バーヘッドを考慮しなければならないので話が複雑になるのだが、 わかりやすくするためCMSオーバーヘッドは無視して、 1stギアの逐次実行で考えてみよう。(EXECユニットの補助も効かないと仮定する。) この場合、消尽されて1個相当になったx86命令を2サイクルで実行する訳だから IPCは1/2x86命令/サイクルである。

ここで、CMSの命令消尽機能が働かない場合を考えてみよう。 この場合、2x86命令を4サイクルで実行するわけだから、 やはりIPCは2/4x86命令/サイクル、つまり1/2x86命令/サイクルで同じある。 動的に命令を消尽してもしなくてもIPCは同じなのである。

この場合、x86命令で考えなくても話は同じである。 atom/サイクルでカウントした場合を考えてみよう。

一方は2atomを2サイクルで、もう一方は4atomを4サイクルで... つまり、IPCはどちらも1atom/サイクルで差はない。 クロックも同じなので、両者の性能に違いはない事になってしまう。

サイクル数 冗長命令消去あり 冗長命令消去無し
サイクル1 命令1 命令1
サイクル2 命令3 命令2
サイクル3 処理終了 命令3
サイクル4 処理終了 命令4
IPC 1命令/サイクル 1命令/サイクル
実実行時間 2サイクル 4サイクル

注意:あくまでもたとえ話である。
実際にこうだと言っているわけでは無いので注意。

しかし、実実行時間を考えて欲しい。 かたや2サイクル、かたや4サイクルとなって2倍もの差が出るのである。 クロックもIPCも同じなのに、実性能に2倍もの差が出るのは、 性能指標として問題がある事を示しているのではなかろうか?

ベンチマークスコアを考えてみると、このことがよく分かる。 ベンチマークは一定のループ処理を行う時間をカウントするか、 または、一定時間の内に何回ループ処理を行うことができるかで 性能を測定している場合がほとんどである。

この場合、CMSが命令を消尽した場合としない場合とでは、 どちらもベンチマークスコアに2倍の差が出る事は明白である。 命令を消尽すれば、ループの実実行時間が短縮されるわけだからね。 1)

☆ベクトル処理もうまく説明できない。   
また、IPCはベクトル処理もうまく説明できない。

ある処理をベクトル処理単一命令と複数のスカラ処理で行う場合を比較してみよう。 例えばYi=Xi+Aという処理をi=1、2、3、4と 連続して行う場合を考えてみる。

サイクル数 スカラ処理 ベクトル処理
サイクル1 命令1(Y=X+A) 命令1(Y=X+A)
サイクル2 命令2(Y=X+A) 命令1(Y=X+A)
サイクル3 命令3(Y=X+A) 命令1(Y=X+A)
サイクル4 命令4(Y=X+A) 命令1(Y=X+A)
IPC 1命令/サイクル 1/4命令/サイクル
実実行時間 4サイクル 4サイクル


4つのデータを処理すると考えると、スカラ処理では4命令を実行する。 一方、ベクトル長4のベクトル命令を一つ実行すると考えると、 ベクトル演算の場合は1命令で4データを処理する。

つまり、同じ処理を行っていても、かたやスカラ処理のIPCは1命令/サイクル。 ベクトル処理では1/4命令/サイクル。 一見するとIPCはベクトル演算の方が小さい。

しかし、両者の性能には何ら差がない事は、上記の表を一目見るだけでわかる。 ベクトル演算命令はILP(Instruction Level Parallelism)を使って性能を 高めるわけではなく、DLP(Data Level Parallelism)を使って性能を 高めているためである。

ちなみに、ベクトル処理では命令1のデコードは1回で済むため、 命令1の2,3,4回目の実行時にはデコーダーやリザベーションユニットには さらに次の命令を発行する準備ができる。 上記の実行時間はどちらも4サイクルであるが、 このことまで考えに入れればベクトル処理の方が性能は上である。

SIMD的な空間系列の並列化でベクトル演算機構を設計してももちろん性能は上がる。 しかし、時系列的な並列化でも、次の命令の準備まで考えれば 性能は上がっていると言える。

話を戻してさらに考えを進め、空間系列多重度2のSIMD処理と時間系列多重度2を 取り入れた複合型のベクトル演算処理を考えてみよう。

サイクル数 スカラ処理 ベクトル処理
サイクル1 命令1(Y=X+A) 命令1(Y=X+A) 命令1(Y=X+A)
サイクル2 命令2(Y=X+A) 命令1(Y=X+A) 命令1(Y=X+A)
サイクル3 命令3(Y=X+A) 処理終了 処理終了
サイクル4 命令4(Y=X+A) 処理終了 処理終了
IPC 1命令/サイクル 1/2命令/サイクル
実実行時間 4サイクル 2サイクル


この場合はもっと奇妙なことが起こる。 つまり、IPCが低いベクトル演算処理の方がIPCの高いスカラ処理よりも 実実行時間が短いのである。クロック周波数は変わらないのに...

☆高速処理技術の進歩によって...   
というわけで、IPCという指標は性能指標としては 使いにくくなってきているのではなかろうか?

これは、EfficeonのCMSに見られる通り、並列度を上げるのではなくムダな命令を 消し去ることで性能を高めるというアプローチが出現したためである。 この場合、クロックもIPCも変化しないが実性能は上がっている。

荷物を運ぶ仕事で例えると、 高クロック化はスポーツカーで素早く運ぶことであると言えるだろう。 一度に運べる荷物は少ないが、何回も往復して速く運ぶのである。 高IPC化はダンプのようなもので、スピードは遅いが一度にたくさん運べるわけだ。

では、Efficeonの手法はどうだろうか?

不要な命令を消去するという方法は、荷物の中から不要なゴミを見つけだして 荷物自体をコンパクトにする事である。 このような場合、ダンプの積載重量が増えなくても運送の仕事は早く終わる。

IPCという指標が出現した当時では、 このような方法(動的コンパイラ等)によって 性能を高めるという考え方そのものがなかっただろう。 想定外の高速化手法の出現によって、IPCという指標の正当性が揺らいでいるのである。

並列に実行される命令が多ければ多いほど高性能という考え方は、 演算ユニットの並列性に由来するハードウエア物量優位的発想で、 命令自体の効率とか命令そのものの短縮という最近の実行効率優位的発想を 巧く表現できていない可能性が高い。

IPCは命令セットが異なれば直接比較できる値ではなく、また、命令セットが同じでも 新たな高速化手法が開発されれば比較できなくなる。 IPCもまた技術革新の波に呑まれつつあると言うことであろうか?

IPCが性能指標として通用しなくなる日は、もうすぐそこまで来ている事は間違いない。

☆さらばIPC   
今我々はIPCという性能指標を捨てて新たな性能指標を 導入すべき時に来ていると思われる。 今後さらに発展が期待される新高速化手法によっても正当性が揺らがない 指標である。 (またはクロック周波数×IPCの他にもう一つの補正項を導入するか...)

これについてはいろいろ考えてみたのだが、 たるさんの貧弱な頭脳では今のところ良いアイディアが見つからなかった。 補正項として命令短縮率を導入すればEfficeonの場合の問題は解決する。 しかし、それ以外の高速化手法が今後新たに出現すれば、やはり対応不能である。

やはり機械音痴の遺伝子を受け継いでいる身としては、 その辺が限界なのだろうか? (これはというアイディアをお持ちの方は是非教えてください。)

ともあれ、新指標が何なのかはともかく、 IPCについては今後役割を終えていくものと推測される。

今までPCマニアを導いてくれた事に感謝しつつも、 「さらばIPC」と言いたい。 2004年はIPC引退の年になるだろう。




1)
Efficeon高性能の秘密は高IPCにあると言われている。 しかし、この考察から分かる通りそれすらも間違いではないかと 最近考えるようになった。

Efficeonは高クロックでもなく高IPCでもなく、このように 実実行時間を短縮することで性能を稼いでいる 傾向があるように思われてならない。

EfficeonのIPCは5.Xatom/サイクルであると言われているが、 これは5.Xatom/サイクル相当という事であって、 リアルなIPCはそこまでは到達していない可能性も大きいのではないだろうか?

これはたるさんの推測であるが、実IPCでは5.Xatom/サイクルをEfficeonは 達成できていないように思う。AMDのモデルナンバーの様に、命令消尽等によって 5.Xatom/サイクル相当ということで達成されているのではないだろうか?

これならTransmeta社がEfficeonのIPC公開を渋っている事も納得がいく。