CPU

CPU とは

CPU (Central Processing Unit、中央処理装置) は、コンピュータの「頭脳」にあたる部品だ。プログラムの命令を一つずつ読み込み、解釈し、計算や制御を実行する。あらゆるソフトウェアの処理は、最終的に CPU が実行する機械語の命令に変換されて動いている。

基本的な動作

CPU は「命令を取り出す (フェッチ) → 解釈する (デコード) → 実行する」というサイクルを、ひたすら高速に繰り返す。命令はメモリ上に並んでいて、次にどこを読むかはプログラムカウンタという内部レジスタが覚えている。デコードで「何をする命令か」「対象はどのレジスタか」が確定し、実行段で演算器が動き、結果をレジスタかメモリへ書き戻す。

指標	意味
クロック周波数	1 秒間に刻む同期信号の回数 (GHz)
コア数	独立して命令を実行できる単位の数
キャッシュ	CPU 内に置かれた高速な一時記憶

ここで注意したいのは、周波数は「1 秒間に何個の命令を実行できるか」ではないことだ。1 つの命令に複数クロックかかることもあれば、後述の仕組みで 1 クロックのあいだに複数の命令が片付くこともある。周波数の数字だけを並べて速さを比べても答えは出ない。

なぜ理解する価値があるか

普段プログラムを書くとき CPU を意識する機会は少ない。しかし、処理が遅い原因を探るとき、大量データを扱うとき、並列処理を設計するときには、CPU の仕組み (キャッシュ、コア、メモリとのやり取り) の理解が効いてくる。コンピュータの性能の限界を理解することは、効率的なコードを書く土台になる。

一度に 1 命令ずつではない

素朴に読むと、CPU は 1 つの命令を終えてから次に取りかかるように思える。実機はそうなっていない。フェッチ・デコード・実行・書き戻しをそれぞれ別の担当に分け、前の命令が実行段にいるあいだに次の命令をデコードする。工場の流れ作業と同じ考え方で、これをパイプラインと呼ぶ。段を細かく割れば 1 段あたりの仕事が軽くなり、その分クロックを上げやすくなる。さらに実行段の演算器を複数持たせ、互いに依存しない命令を同じクロックで並行して片付ける造りも一般的だ。だから「1 クロックで 1 命令」という単純な換算は成り立たない。

流れ作業の弱点は分岐だ。if の判定結果が出るまで、次にどの命令を流し込むべきかが決まらない。止まって待てばパイプラインが空になるので、CPU は「たぶんこちら側へ進む」と予測して先に流し込んでおく。これが分岐予測と投機実行で、当たれば損失はほぼゼロ、外れたら流し込んだ分を破棄して取り直すため段数の分だけ空転する。ループの継続判定のように毎回同じ向きへ進む分岐はほぼ確実に当たり、データ次第で向きが変わる分岐は当たりにくい。「条件判定をループの内側から外へ出す」「分岐を算術演算に置き換える」といった定石は、この空転を減らすための工夫だ。

待ち時間の階層を数字で見る

「計算は速いのにデータの取り寄せで待つ」がどれほどの差なのかは、測ると腹に落ちる。ポインタを次々にたどるだけの処理で、たどる範囲の広さだけを変えて 1 回あたりの所要時間を測ると次のようになった (Apple M3 Pro での手元実測・2026 年 8 月時点)。

たどる範囲	1 回あたり	収まる場所
64KB	1.4 ns	コア直結の 1 次キャッシュ
4MB	9.5 ns	コア群が共有する 2 次キャッシュ
256MB	113 ns	主記憶 (DRAM)

同じ「1 回のメモリ参照」でも、キャッシュに収まるかどうかで 80 倍の開きが出る。数 GHz の CPU にとって 113 ns は数百クロック分にあたり、その間に実行できたはずの命令が丸ごと失われる。だから性能改善の勘所は、演算の回数を削ることより「触るデータを狭い範囲に固めてキャッシュに載せる」ことに寄っていく。配列を順に走る処理が連結リストを飛び回る処理より速いのも、同じデータを構造体の配列で持つか配列の構造体で持つかで速度が変わるのも、この階層が理由だ。ストレージになるとさらに 2 桁から 3 桁遅く、SSD でもマイクロ秒の単位になる。

周波数を上げる時代が終わった理由

2000 年代半ばまで、性能向上の主役はクロック周波数の引き上げだった。それが止まったのは電力と発熱の都合だ。周波数を上げるには回路の切り替えを速くする必要があり、そのために電圧を上げると消費電力は電圧の二乗で増える。発熱が冷却の限界に突き当たり、周波数を伸ばし続ける路線が成り立たなくなった。以後の増強は、コアを増やして複数の処理を同時に走らせる方向へ移っている。

手元の Apple M3 Pro を見ると、11 個のコアが性能重視の 5 個と電力効率重視の 6 個に分かれている (2026 年 8 月時点の実測)。性格の違うコアを混ぜるのは、すべてを全力型にするより電力あたりの仕事量が稼げるからだ。ただしコアが増えても、プログラム側が処理を分けられなければ 1 コア分の速さしか出ない。

性能を追うときの見方

• どこで待っているかを先に測る。 演算が足りないのか、メモリ参照で待っているのか、そもそも入出力待ちなのかで打ち手が正反対になる。推測で最適化に入ると、たいてい効かない場所を磨くことになる。
• データの置き方を疑う。 上の実測どおり、参照範囲がキャッシュに収まるかどうかで桁が動く。アルゴリズムの計算量が同じなら、次に効くのはメモリ上の配置だ。
• 並列化の効果はコア数より「分けられる割合」で決まる。 処理の半分が分割できないなら、8 コア使っても約 1.8 倍、コアを無限に増やしても 2 倍が上限になる (アムダールの法則)。コアを足す前に、分割できない部分を削るほうが先だ。

ハードウェアの理解は、こうした「どこを直せば効くのか」の判断を支える足場になる。