そもそもCPUとは何なのか。これをどこまで掘り下げるかは難しいところで，例えばバベッジの計算機械（階差機関）までさかのぼったら，さすがに誰も読む気をなくすだろうし，あるいは「んじゃ原理的に」ということで，ブール代数の話を始めても，やっぱり読まれなくなることは明白だ。あるいは，「では電気の基礎から」と，半導体についての解説や真空管の動作原理から始めたら，きっと編集部から怒りの鉄槌が下されてしまうだろう。
　というわけで，こういった昔の話や基礎の基礎についてはざっくり割愛して，ゲームとCPUの関わり合いについて話をしていきたいと思うが，ゲームを動作させるとき，CPUが行うべき処理はきわめて多岐にわたっている。具体的には，以下のような処理を同時に行わねばならない。

　いきなり動作クロックの話をしたので，要するに動作クロックが高ければいいのか，と思うかもしれないが，話はそう単純ではない。
　図1は，CPUの構造をとことん単純化したものだ。大別すると，「フェッチ（Fetch）」「デコード（Decode）」「エグゼキュート（Execute）」「ライトバック（Write Back）」という4ステージに分類される。それぞれの機能は大まかにいって以下のとおり。

　さて，初期のCPUはこの4ステージをのんびりと実行していた。フェッチ→デコード→エグゼキュート→ライトバックが各1サイクルで処理できると仮定すると，一つの命令を完全に終了するには4サイクルかかるといったイメージである。
　また新しい言葉が出てきた。「サイクル」は「Cycle」のことで，元々は動作クロックのHzと同じ意味である。かつては「東日本の交流は50サイクル」などと呼んでいた時代もあった。その後，周波数の単位はHzに統一されたため，今では「東日本の交流は50Hz」と呼ぶのが当たり前だが，ではその50Hzの交流の波形1個1個を数えるときには，現在でもサイクルを単位にすることが慣習として残っている。だから上の文章も「一つの命令を完全に終了するには4Hzかかる」と書き換えても間違いではない。ちなみに「サイクルタイム（CycleTime）」という言葉もあり，これは1サイクルにかかる時間，要するに1秒をサイクルで割ったものになる。つまり50Hzの場合，サイクルタイムは1/50秒＝20ms（20ミリ秒）だ。

　というわけで，4サイクルはあまりに効率が悪い。そこで考え出されたのが「パイプライン（Pipeline）」という方式である。フェッチ・デコード・エグゼキュート・ライトバックを同時に独立して実行できるようにすると，一度に処理できる命令の数は，パイプライン構造を採っていないとき（図2上）と比べて4倍に増える（図2中）。
　これは，バケツリレーをイメージすると分かりやすい。水を100m運ぶとして，一人でこれを運ぶとなると，運べる量はたかが知れている。ところがこれを25mづつ4区間に分け，4人が25mづつ運ぶようにすれば，運べる量は時間あたり4倍になる。
　もっとも，25mは一人で運ばなければいけないから，まだ高速化の余地がある。100mを100分割して100人連れてくれば，ほとんど歩かずにバケツの受け渡しができるようになるから，運べる量は圧倒的に増えるだろう。こうした具合で，パイプラインをさらに細分化して高速化するのが「スーパーパイプライン（Super Pipeline）」という技法である（図2下）。

　パイプラインやスーパーパイプラインが一般的に採用されるようになったことで，パイプライン段数も増えてきた。Pentiumシリーズで見てみると，7〜8段（Pentium）→10段（Pentium II/III）→20段（Willamette/NorthwoodコアPentium 4）→31段（PrescottコアPentium 4）といった感じだ。
　ではなぜ，パイプライン段数が増えてきたのだろうか。

　先ほど説明したCPUのパイプラインは，半導体の主力構成要素である「トランジスタ」という素子を組み合わせて構成されている。
　ここで仮に，図4上のようなパイプラインにおいて，各段がいずれもトランジスタ10個を直列に並べた構造でできているとしよう。このトランジスタが各1ns（1ナノ秒，1ナノは10のマイナス9乗）で動作すると仮定すると，パイプラインの各段はトランジスタ10個分＝10nsで処理が完了する。サイクルタイムは周波数の逆数で1ns＝1GHzだから，10nsは100MHz。この構成では，動作クロックを100MHz以上にすると，トランジスタの速度が追いつかないことになる。

　では，パイプラインを図4下のように分割し，パイプライン各段が5トランジスタで構成されるように作り替えたらどうなるだろう？　各段の処理が終わるまでの時間は5nsに短縮されるから，200MHzまで動作クロックを上げられるようになる。
　この例はあまりに単純化しすぎというきらいはあるものの，実際のCPUとパイプラインの関係はおおむねこんな感じと思っていい。パイプラインの段数が増えると，動作クロックを上げやすくなるのだ。

　なら，ひたすらパイプライン段数を増やせばいいかといえば，パイプライン段数を増やして動作クロックを上げると，副作用も大きい。その最たるものが「パイプラインハザード（Pipeline Hazard）」と呼ばれる現象である。少々難しくなってしまうが，以下の図5に挙げるようなプログラムがあると仮定して説明してみたい。

　これを，図2に出てきた8段のスーパーパイプラインで実施することを考えてみよう。まず（2）（※図の中では"まる2"だが，機種依存文字になってしまうので，本文では"括弧2"のように表記する）の判断でr30が0でないとき，パイプラインは以下に挙げる図6の左側ようにスムーズに進む。では，r30が0だったらどうなるかというと，図7のようになる。（2）の処理を受けて，（3）が次の命令の飛び先を決めるのは，Execute2のステージだから，スタートしてから8サイクルめになる。この時点でパイプラインには（4）や（5）の命令がすでにロードされており，一方（6）や（7）の命令はロードされていない。この場合パイプラインは9サイクルめに，（4）や（5）の命令をクリアする処理（これを「パイプラインフラッシュ」と呼ぶ）を行い，10サイクルめ以降に改めて（6）や（7）の命令をロードして処理をはじめることになる。結果として，図6では12サイクルで一連の処理が終るのに対し，図7では18サイクルかかる。余分な処理時間が50％分も生じてしまう計算だ。

　こうした問題は，段数が増えたりアウトオブオーダーを実装していたりするとさらに深刻で，それだけで数百サイクル消費してしまうケースすらある。加えて，正しい処理先（図7でいうところの（6）や（7））の命令がキャッシュに入っていなかったりすると，その命令をメモリから読み出す必要が出てくるため，遅延は数千サイクルに達しても不思議ではない。 　これを一般に，「分岐」によるペナルティという。分岐というのは，今回の例でいうと（3）にあたる処理のこと。（3）で，処理の流れは文字通り2系統に分岐する。どちらに行くのかは条件次第（今回の例ならr30というレジスタの値次第）だから，あらかじめこれを判断しておくのは不可能だ。だから「例えば（3）の次は（4）・（5）と行くはずだ」と思い込んでいて，実は（4）に行かず（6）に飛んだりすると，図7のようなパイプラインハザードが起こるわけである。
　こうした分岐によるペナルティは，とくに最近のCPUでは無視できない。実際，処理時間全体のうちの30％強が分岐ミスのリカバリー，1割強がメモリアクセス待ちに費やされ，純粋にCPUが処理に費やす時間は50％そこそこ，などといった数字もあるほどだからだ。

　以上については，かなり難易度が高いので，またメイドさんにお出まし願おう。邸宅でちょっとしたパーティーが開かれるとする。そこで執事はメイドさんを大量動員して，料理の準備を進めるわけだ。品数も多いので，買出し・下ごしらえ・調理・配膳と分担して，それぞれ何人かのメイドさんを割り当てて作業を行っている。
　さて，食前酒やスープに続いて前菜の処理に取りかかったあたりで，初めて「出席者がベジタリアン集団だった」なんてことが分かったりすると，大騒ぎになるのは目に見えている。とりあえず作りかけの前菜（や，場合によっては食前酒，スープ）を賄い飯にするといった程度で済めば幸せで，ステーキやら鳥料理の下ごしらえは全部無駄になるだろうし，そのベジタリアンが「チーズやバター・卵も駄目」だったりすると，メニュー自体を全部考え直す必要があるかもしれない。こうなると，そもそも買い込んでおいた食材では料理を出せないかもしれないから，急遽メニューを決め直して，買出しを急がないといけない。
　これは小規模のパーティなら「ちょっとしたトラブル」のレベルだが，メイドさん数十人とか数百人とかで準備してきたパーティとなると「大惨事」である。分岐ミスというのはこの場合「メニューの判断ミス」なので，「んなもん事前に調べておけ馬鹿者」とご主人様に怒られるわけだが，CPUがやっかいなのは，これを事前には調べられない点にある。可能なのは「前回はこんな感じのメニューで好評だったから，今回はこれで行こう」と"予測"することだけ。したがって，大惨事を引き起こさないように「どこまで精密に予測するか」が大変重要になるわけだ。

　話を戻すと，こうした大規模な分岐ミスを起こさないよう，分岐命令に関しては「それはどこに分岐するか」を予測して，分岐ミスを減らそうという仕組みが用意されている。この分岐予測のメカニズムは色々あり，単純に「直前の分岐がどちらに向かったか記憶している」レベルのものから，ループ制御（ある条件を満たすまでプログラムの一部を繰り返し実行すること）などを動的に解釈して予測するもの，過去の分岐履歴をずっと記録して判断するものなども存在する。また，分岐ミスしたときにどうやってリカバリを高速化するか，という観点での強化も行われており，これもさまざまな形で実装されている。極端な例だと，（本誌読者にはあまり関係のない）「Itenium」（アイテニウム）というサーバー向けCPUでは，図5の（3）において，分岐方向の結果が出る前に（4）（5）と（6）（7）の両方をパイプラインに乗せておき，間違ったほうを捨てるという強烈な仕様となっている。