ジョン・ヘネシーの性能スケーリングに関するアーキテクチャ観

なぜヘネシーの考え方は現代の性能に今も重要か

ジョン・ヘネシーは、コンピュータがなぜ速くなるのか、そしてその進歩が時に停滞する理由を最も明快に説明した設計者の一人です。影響力あるプロセッサを作り、RISCの考え方を広めただけでなく、システム設計者が性能の判断を行うための実用的な語彙――何を最適化すべきか、何を最適化すべきでないか、どうやって見極めるか――を提供しました。

人々が「性能スケーリング」と言うとき、多くは「プログラムが速く動く」という意味で使います。実際のシステムでは、スケーリングは速度（speed）、コスト（cost）、**消費電力／エネルギー（power/energy）**という三者の交渉です。ある変更であるワークロードが20%速くなっても、チップが高価になったり、サーバーの冷却が難しくなったり、バッテリの消耗が早くなったりします。ヘネシーのフレーミングが重要なのは、これらの制約を「想定すべき通常の工学的入力」として扱っている点です。驚きの問題ではなく、設計時に組み込むものです。

本稿で使う三つのテーマ

まずは並列性（parallelism）：同時により多くの作業を行うこと。これはコア内部（命令レベルのトリック）、コア間（スレッド）、マシン全体にまたがって現れます。

次は特化（specialization）：仕事に適した道具を使うこと。GPU、映像エンコーダ、MLアクセラレータが存在するのは、汎用CPUでは効率的にすべてをこなせないからです。

三つ目はトレードオフ（tradeoffs）：すべての「勝ち」は代償を伴います。重要なのは、制限がどこにあるかを理解すること――計算、メモリ、通信、またはエネルギーか。

期待すること

これは伝記の深掘りではありません。代わりに、ベンチマークを読むとき、ハードウェアを選ぶとき、需要とともに成長するソフトウェアを設計するときに適用できる実践的な概念のセットです。

「無料の」高速化から現実的な限界へ

長い間、性能改善はほとんど自動的に感じられました。トランジスタが小さくなると、チップメーカーはより多くのトランジスタをプロセッサ上に詰め込み、しばしばクロック周波数も上げられました。ソフトウェアチームは同じプログラムを新しいマシンで動かすだけで、再設計なしにより速く動くのを見ました。

「無料の性能」時代

新しいCPU世代が高いGHz、トランジスタ当たりのコスト低下、日常コードでの体感速度向上をもたらした時期です。その多くの利得は開発者が意識的に何かを変えなくても得られました。コンパイラやハードウェアの進化が重荷を担ってくれました。

「電力の壁」がルールを変えた理由

やがて、高クロックは単純な勝利ではなくなりました。電力と熱が急速に増加するためです。トランジスタを小さくしても以前のように自動的に電力が減るわけではなく、周波数を上げればチップはより熱を持ちます。ある時点で制限要因は「より速くできるか」ではなく「冷却と供電を確実に行えるか」になりました。

単純なアナロジー：自動車のエンジンと熱・燃料

エンジンを例にとると、高回転にすれば速く走れますが、燃料消費が跳ね上がり、部品が過熱し、システムが危険になります。CPUも似た境界に達します：回転数（クロック）を上げることは、エネルギー面で不釣り合いにコストが増え、熱を生み出します。

「無料の」速度向上から賢い設計へ

クロックスケーリングが鈍化すると、性能は設計で「稼ぐ」ものになりました：より多くの並列作業、キャッシュやメモリの賢い活用、特化ハードウェア、そして慎重なソフトウェア設計。ヘネシーのメッセージはこの変化に合致します：大きな利得はハードとソフトの全体が協調することで得られるのであって、次のチップが自動的に救ってくれると期待するわけにはいかない、ということです。

命令レベル並列性（ILP）：利得と逓減する収穫

命令レベル並列性（ILP）は、1つのCPUコア内部で「小さなステップを同時に行う」考え方です。プログラムが“シングルスレッド”でも、プロセッサはしばしば作業を重ねて行えます：ある命令が何かを待っている間に、依存関係がなければ別の命令が進められます。

パイプライニング：組み立てライン効果

ILPをイメージする簡単な方法はパイプラインです。組み立てラインのように、ある段が命令をフェッチし、別の段がデコードし、また別の段が実行し、最後の段が結果を書き戻す。パイプラインが満たされると、各命令は複数段を通るにもかかわらず、CPUは概ね1サイクルあたり1命令を「完了」できます。

パイプライニングは、プログラマがすべてを書き直す必要なくスループットを向上させるため、長年にわたり性能を押し上げました。

分岐予測：パイプラインを途切れさせない工夫

実際のプログラムは直線的に実行されません。分岐（「もし〜なら」）があり、CPUは次に何をフェッチするかを決めなければなりません。待っているとパイプラインが止まってしまいます。

分岐予測は、CPUが次の経路を“推測”して作業を流し続ける方法です。当たりなら性能は保たれます。外れると、CPUは間違った経路の作業を捨て、その分のサイクルとエネルギーを失います。

コスト：複雑さ、電力、そして収穫逓減

ILPをさらに推し進めるには、独立した命令を見つけて安全に並べ替え、誤り（分岐ミスなど）から回復するためのより多くのハードウェアが必要です。それは複雑さと検証努力を増し、電力消費を増やし、世代ごとに得られる利得が小さくなることが多いです。

これはヘネシーの繰り返しの教訓の一つです：ILPは有効ですが実用的な限界にぶつかる。したがって、持続的な性能スケーリングは単一コアの「より賢い」実行だけではなく、他の手段を必要とします。

アムダールの法則：大きな判断の背後にある単純な数学

アムダールの法則は、仕事の一部を速くしても、残りの遅い部分が許す以上に全体を速くすることはできない、という単純な注意喚起です。重い数学は必要なく、並列化できない部分を見抜くだけで十分です。

日常的な例

小さなスーパーのレジを想像してください：

• バーコード読み取りは複数のレジに分散できます（並列作業）。
• 支払い（1枚のカード、1枚のレシート）は依然として単一の段階です（直列作業）。

支払いが常に総時間の10%を要するなら、読み取りを瞬時にしても全体では約10倍を上限にしか速くなりません。直列部分が天井になります。

料理も同じパターンです：野菜は刻みながら水を沸かす（並列）ことはできますが、オーブンで30分焼くケーキは「並列化」できません。

なぜ小さな直列部分が全体を支配するのか

重要な洞察は、直列作業の最後の数パーセントが全体を制限するという点です。「99%が並列」のプログラムは魅力的に聞こえますが、多くのコアにスケールさせると残りの1%が長い棒（ボトルネック）になります。

これがアーキテクチャ判断に与える影響

アムダールの法則は「コアを追加すれば良い」という期待がしばしば裏切られる理由を説明します。コアを増やして効果があるのは、十分な並列作業があり、同期、I/O、単一スレッド段階、メモリ待ちなどの直列ボトルネックが小さい場合だけです。

また、アクセラレータが厄介な理由も分かります：GPUがあるカーネルを速くしても、パイプラインの残りが直列のままなら、全体的な利得は控えめです。

経験則

並列化に投資する前に問うべきは：どの割合が本当に並列で、どの部分が直列のままか？ 時間を実際に使っている場所――しばしば「退屈な」直列経路――に労力を払うことが重要です。そこが限界を決めます。

スレッドレベル並列性（TLP）：マルチコアへの移行

長年、性能向上は主に単一CPUコアを速くすることを意味しました。しかしそのアプローチは実用上の限界に達しました：クロックを上げれば熱と電力が増え、深いパイプラインが実際のスピードアップに直結しないこともありました。メインストリームの解は、1つのチップ上に複数のコアを載せ、より多くの作業を同時に行わせることでした。

1つのタスクを速くするか、より多くのタスクを処理するか

マルチコアは二つの異なる方法で役立ちます：

• 1つの仕事を速くするために、それを並列の部分に分割する（1プログラム・多数スレッド）。
• より多くの仕事を同時に実行する（多くのプログラムがそれぞれ独立したスレッドやプロセスを持つ）、これは単一の仕事が速くならなくても応答性やスループットを改善します。

この区別は計画上重要です：サーバーは同時により多くのリクエストを捌けることで即座に恩恵を受けるかもしれませんが、デスクトップアプリが速く感じられるには自分自身の処理が並列化される必要があります。

ソフトウェアが恩恵を受けるためにすべきこと

スレッドレベル並列性は自動ではありません。ソフトウェアはスレッド、タスクキュー、あるいは仕事を独立単位に分解するフレームワークを使って並列作業を明示する必要があります。目的は、コアが互いに待ち続けることなく稼働し続けることです。

一般的な実践としては、ループの並列化、独立した段階の分離（例：デコード→処理→エンコード）、複数リクエスト／イベントの同時処理などがあります。

摩擦点：調整と共有資源

マルチコアのスケーリングは多くの場合オーバーヘッドで停滞します：

• 調整コスト：ロック、競合、スケジューリング、同期は追加コアの利点を消し去ることがあります。
• 共有資源：複数コアがキャッシュ、メモリ帯域、I/Oを競合します。コアを増やしてもメモリ速度が自動的に増えるわけではありません。

ヘネシーの広いメッセージはここにも当てはまります：並列性は強力だが、実際のスピードアップは慎重なシステム設計と正直な測定に依存します。単にコアを増やすだけでは不十分です。

メモリと隠れたボトルネック

CPUは手元にあるデータでしか作業できません。データがまだメモリから届いていない場合、CPUは待たなければなりません。その待ち時間が**メモリ遅延（memory latency）**であり、それが高いと「高速な」プロセッサが高価な遊休機械になってしまいます。

遅延：データを待つコスト

メモリを町はずれの倉庫に例えると、作業者（CPUコア）がいくら速くても、部品が渋滞で届かなければ組み立ては進みません。現代プロセッサは毎秒何十億回もの演算を実行できますが、主記憶への往復は数百サイクルかかることがあります。そのギャップが積み重なります。

キャッシュ：近くの棚に頻繁に使うものを置く

待ち時間を減らすために、コンピュータはCPUに近い小さく速いメモリ領域であるキャッシュを使います。必要なデータが棚にあれば（「キャッシュヒット」）、作業はスムーズに続きます。なければ（「ミス」）、CPUは遠くから取り寄せなければならず、完全な遅延を支払います。

帯域幅と遅延（両方が必要な理由）

遅延は「最初のアイテムが届くまでの時間」です。帯域幅は「1秒あたりに何個のアイテムが届くか」です。広い道路（高帯域）でも距離が長ければ遅延は大きいままです。あるワークロードは大量のデータをストリームする（帯域幅が支配的）、別のワークロードは小さく散発的なアクセスを多くする（遅延が支配的）――どちらでもシステムは遅く感じることがあります。

メモリの壁

ヘネシーの「限界」に関する考えはここでメモリの壁として現れます：CPU速度は長年メモリアクセス時間よりも速く改善してきたため、プロセッサが待ち時間で停滞することが増えました。だから性能向上はデータ局所性の改善（キャッシュが効くようにする）、アルゴリズムの再検討、システムバランスの見直しから来ることが多く、単にコア自体を速くするだけではありません。

電力は第一級の制約である

長い間、「速い」＝「クロックを上げる」と考えられていましたが、電力を厳密な予算として扱うとその考えは崩れます。余分なワットは熱になり、取り除かねばならず、バッテリを消耗し、電気代を増やします。性能は依然として目標ですが、何が出荷可能でスケールするかを決めるのはワット当たりの性能（performance per watt）です。

中核的トレードオフ：速度対エネルギー

電力は単なる技術的詳細ではなく、製品制約です。ベンチマークで良いスコアを出しても2分でサーマルスロットリングするノートPCは使っていると遅く感じます。瞬時にページを描画するがバッテリを20%消費するスマホも良い取引ではありません。サーバーでも、計算余力があっても電力や冷却に余裕がなければ使えません。

なぜ周波数向上は急速に高コスト化するのか

周波数を上げると電力は急速に増えます。安定した高クロックにはしばしば高電圧が必要で、スイッチング活動の増加がそのままエネルギー消費につながります。単純化すると動的電力はおおよそ以下のように振る舞います：

• スイッチング作業が増える（周波数上昇）と秒当たりのエネルギー消費が増える
• 電圧が上がるとコストが乗数的に増える

したがって最後の10〜20%のクロック向上はワット数の大きなジャンプを要求し、持続的な利得ではなく熱的制限とスロットリングを招きます。

実際の帰結：モバイル、データセンター、クラウド請求

これが現代の設計が効率性を重視する理由です：並列性の幅広い活用、賢い電力管理、「十分な」クロックを適切なマイクロアーキテクチャと組み合わせること。データセンターでは電力はハードウェア費用に匹敵するランニングコストです。クラウドでは非効率なコードは直接請求額を膨らませます――時間、コア、（間接的に）エネルギーに対して支払うためです。

ハードウェア–ソフトウェア共同設計という戦略

ヘネシーの繰り返しのポイントは単純です：性能スケーリングはハードだけの問題でもソフトだけの問題でもありません。ハードウェア–ソフトウェア共同設計とは、CPU機能、コンパイラ、ランタイム、アルゴリズムを実際のワークロードに合わせて整合させ、スペック表ではなく実際に走らせるものに対してシステムを速くすることです。

実践での共同設計の姿

古典的な例はコンパイラ支援によってハードウェア機能を引き出すことです。プロセッサが幅の広いベクトルユニット（SIMD）、分岐予測、あるいは複数操作を融合する命令を持っていても、ソフトがコンパイラを使いやすく構築していなければ機能は活きません。

• 自動ベクトル化：配列を順に走る明確なループでポインタエイリアシングの問題がなければ、コンパイラはベクトル命令を生成しやすくなります。
• プロファイルガイド最適化（PGO）：実際の実行プロファイルを使ってコンパイルすると、コード配置を入れ替えたり分岐の振る舞いを改善でき、分岐ミスでCPUが待つ時間を減らせます。
• データ配置の選択："array of structs"から"struct of arrays"に変えるとメモリアクセスが規則的になり、キャッシュやプリフェッチが効きやすくなります。

なぜ「より速いハード」だけでは失望しがちか

ボトルネックがメモリ遅延、ロック競合、I/Oであれば、高いクロックやコアの追加はほとんど効果がありません。システムは同じ限界に達するだけです。ソフトウェアの変更――より良い並列構造、キャッシュミスの削減、同期の減少――がなければ新しいハードウェアは遊休状態になります。

実践的な共同設計チェックリスト

プラットフォームや最適化を検討するときは次を問います：

1. ワークロード：上位1〜3の重要なタスク（リクエスト、クエリ、フレーム、ジョブ）は何か？
2. ボトルネック：時間は計算、メモリ、同期、I/Oのどれに使われているか？
3. 測定可能な目標：どの指標（p95レイテンシ、スループット、タスク当たりのエネルギー）がどれだけ改善するか？

RISCと単純さの価値

RISC（Reduced Instruction Set Computing）はスローガンというより戦略的な賭けです：命令セットを小さく規則的に保てば、それぞれの命令を速く予測可能に実行できます。ジョン・ヘネシーは、命令セットを簡潔に保つことで、たとえソフトウェア側で命令数が増えても性能改善につながるという考えを広めました。

「単純な命令」がもたらす利点

簡潔な命令セットは一貫したフォーマットと単純な操作（ロード、ストア、加算、分岐）を持つことが多く、その規則性によってCPUは：

• 命令を素早くデコードできる
• パイプラインを満たしやすくなる（命令の意味を“考える”時間が減る）
• 内部ユニット間で効率的に作業をスケジュールできる

命令が扱いやすいと、プロセッサは管理や例外処理に費やす時間を減らし、より多くの時間を有用な作業に使えます。

単純さが性能と効率を両方改善する理由

複雑な命令はプログラムに必要な命令数を減らすことがありますが、ハードウェアの複雑さを増し――回路、例外処理、制御ロジックにより多くの電力がかかります。RISCはこれを逆手にとり、単純な構成要素を使い、コンパイラとマイクロアーキテクチャで速度を引き出します。

それはエネルギー効率にもつながります。オーバーヘッドや制御に無駄なサイクルを使わない設計は、より少ないジュールで済む傾向があり、電力と熱が動作周波数を制約する状況では重要です。

現代システムにおけるRISCの現れ方

スマホ、ノートPC、サーバーの現代CPUはRISC的な原則を多く取り入れています：規則的な実行パイプライン、単純な操作の最適化、コンパイラへの強い依存。ARMベースのシステムはRISCの系譜が主流に到達したわかりやすい例ですが、重要なのは「どのブランドが勝つか」ではなく、スループット、効率、スケールしやすさを可能にする単純さを選ぶことです。

特化とアクセラレータ：汎用CPUでは十分でないとき

特化とは、汎用CPUにすべてを任せる代わりに、あるクラスの仕事を非常に効率的に行うハードウェアを使うことです。一般的な例は、グラフィックスや並列計算に強いGPU、行列演算に特化したAIアクセラレータ（NPU/TPU）、H.264/HEVC/AV1などのための固定機能ブロックです。

なぜアクセラレータは速く、かつ省電力になり得るか

CPUは柔軟性のために設計されています：多くの命令、制御ロジック、分岐コードの高速処理。一方でアクセラレータはその柔軟性を犠牲にして効率を得ます。チップの予算を実際に必要な演算（例えば乗算蓄積）に集中させ、制御オーバーヘッドを最小化し、精度が許すなら低精度（INT8やFP16）を利用します。

この集中によりワット当たりの仕事量が増えます：命令数が減り、データ移動が少なくなり、より多くの並列実行が可能になります。レンダリング、推論、エンコードのような繰り返しの多いカーネルが支配的なワークロードでは、劇的な速度向上と電力管理が得られます。

無視できないトレードオフ

特化にはコストがあります。柔軟性を失うかもしれません（そのハードはある仕事には強く、他では平凡です）、設計と検証のコストが増え、ドライバ、コンパイラ、ライブラリといったソフトウェアエコシステムに依存します。それらが遅れるか、ベンダーロックインを招くこともあります。

いつ特化が価値ある選択か

アクセラレータを選ぶべき条件は：

• ワークロードが計算予算の主要かつ繰り返しの部分である
• 計算が安定していてよく理解されている（アルゴリズムの変化が少ない）
• 性能やエネルギーに厳しい制約（バッテリ、サーマル、データセンターの電力）がある
• それ用の成熟したツールとライブラリを利用できる、または導入できる

ワークロードが不規則で変化が速い、あるいはソフトウェアコストが節約を上回る場合はCPUに留まるほうがよいでしょう。

トレードオフ：どんなアーキテクチャ決定にも代償がある

コンピュータアーキテクチャにおけるすべての性能「勝ち」は請求書を伴います。ヘネシーの仕事は何度も実用的な真実に戻ってきます：システムを最適化するとは、何を犠牲にするかを選ぶことです。

回避できない主要なトレードオフ

何度も現れる緊張関係は次の通りです：

• レイテンシ対スループット：1つのリクエストを速く終わらせる（低レイテンシ）か、1秒あたりにより多くのリクエストを処理する（高スループット）か。対話的なタスク向けに調整されたCPUはより「応答が良く」感じ、バッチ処理向けの設計は総作業量を追い求めます。

• 単純さ対機能：単純な設計は最適化、検証、スケールが容易です。機能が豊富な設計は特定のワークロードを助けますが、共通ケースを遅くする複雑さを招くことがあります。

• コスト対速度：速いハードは通常高価です――シリコン面積、メモリ帯域、冷却、エンジニアリング時間が増えます。しばしば最も安い「速度向上」はソフトやワークロードの変更です。

ある指標が改善すると他が悪化することが多い

単一の数値に最適化してしまい、ユーザーの実体験を損なうのは簡単です。例えば、クロックを上げれば電力と熱が上がり、結局スロットリングで持続性能が落ちます。コアを増やせば並列スループットは改善するかもしれませんが、メモリ競合が増えて各コアの有効性が下がることがあります。大きなキャッシュはミスを減らしてレイテンシを改善しますが、チップ面積とアクセスあたりのエネルギーを増やすためコストと効率が悪化します。

ワークロードのために設計せよ、虚栄のためにではない

ヘネシーの性能観は実利的です：関心のあるワークロードを定義し、その現実のために最適化せよ。

ミリオン単位の同様なリクエストを処理するサーバーは予測可能なスループットとタスク当たりのエネルギーを重視します。ラップトップは応答性とバッテリ寿命を気にします。データパイプラインは総ジョブ時間が短くなるなら高めのレイテンシを受け入れるかもしれません。ベンチマークや見出しのスペックは有用ですが、実際のユースケースと合っているかが重要です。

後で実装できるメモ

「Decision / Helps / Hurts / Best for」のような小さな表を追加すると良いでしょう。行には「コア数の増加」「キャッシュ容量の増大」「周波数向上」「ベクタ幅の拡大」「高速メモリ」などを入れて、トレードオフを具体化し、結果に結びつけて議論できます。

自分を騙さない性能測定法

性能主張はそれを支える測定の質に依存します。ベンチマークは正確でも、実ワークロードに似ていなければ誤解を招きます：データサイズ、キャッシュ挙動、I/Oパターン、同時実行、読み書き比などが異なれば結果は逆転します。ヘネシー流の設計者はベンチマークをトロフィーでなく実験として扱います。

ユーザー体験を説明する指標

スループットは単位時間あたりに完了した仕事量（リクエスト/秒、ジョブ/時）で、容量計画に有効ですがユーザーは平均値を感じません。

テールレイテンシは最も遅いリクエストに注目します（p95/p99）。平均レイテンシが良くてもp99がひどいことはよくあり、その原因はキューイング、GCの一時停止、ロック競合、ノイジーネイバーなどです。

**利用率（Utilization）**はリソース（CPU、メモリ帯域、ディスク、ネットワーク）がどれだけ「忙しい」かを示します。高利用率は良いこともありますが、長いキューを作ってテールレイテンシを押し上げる境界に入ると問題です。

実践的な評価ループ

再現可能なループを使いましょう：

1. 測定：代表的な入力と現実的な同時実行で測る。
2. ひとつだけ変える：コンパイラフラグ、スレッド数、データ配置、キャッシュ方針、ハード設定など。
3. 再測定：平均だけでなく変動やテールも比較する。

設定、バージョン、環境を記録して再現できるようにしておきます。

自己惑わしを避ける

「最も良い実行」をつまみ食いしたり、有利に見えるデータセットだけを選んだり、ひとつの都合の良い指標で過度に一般化してはいけません。あるマシンやベンチでの勝ちがあなたのデプロイやコスト制約、ピーク時トラフィックで通用するとは限りません。

主要なまとめと今日への応用

ヘネシーの持続するメッセージは実践的です：性能は幻想や願望でスケールするのではなく、正しい種類の並列性を選び、エネルギー制約を尊重し、実際に重要なワークロードに対して最適化するときにスケールします。

戦略的教訓

並列性が主要な道ですが、それは決して「無料」ではありません。命令レベル並列性、マルチコアスループット、アクセラレータのどれを追うにせよ、初期の簡単な利得は尽き、調整オーバーヘッドが増えます。

効率は機能である。エネルギー、熱、メモリ移動はしばしばピークGHzよりも先に現実の速度を抑えます。電力やメモリ制限の内で動かない速い設計はユーザーに可視化された勝利をもたらしません。

ワークロードに焦点を当てることが汎用最適化に勝る。アムダールの法則は時間がかかる場所に努力を払えと教えます。まずプロファイルし、次に最適化する。

ビルダー向け実践チェックリスト

• 測定から始める：アーキテクチャ変更を決める前に主要なボトルネック（CPU、メモリ、ストレージ、ネットワーク）を特定する。
• 計画段階でアムダールの法則を使う：並列化に投資する前に最大利得を見積もる。
• 単純でスケーラブルな設計を好む：例外が少ないほど予測可能性とチューニングが容易になる。
• 電力とコストを早期から制約として扱う：後回しにしない。
• ハードをプロダクトに合わせる：ワークロードが安定して大きければGPU/ NPUを検討する。

日常的なソフトウェア構築との接点

これらのアイデアはCPU設計者だけのものではありません。アプリ構築でも同じ制約はキューイング、テールレイテンシ、メモリ圧迫、クラウドコストとして現れます。共同設計を実装する実用的な方法は、アーキテクチャ判断をワークロードフィードバックに近づけることです：測定、反復、出荷。

チャット駆動のビルドワークフローを提供するKoder.aiのようなプラットフォームを使うチームにとって、これは特に有効です。サービスやUIを素早くプロトタイプし、プロファイリングとベンチマークで並列化（例：リクエストの同時処理）を進めるべきか、データ局所性を改善すべきか（往復を減らす、クエリを絞る）、あるいは特化を導入すべきかを判断できます。プラットフォームのplanning mode、snapshots、rollbackは、性能に影響する変更を段階的に試すのを容易にし、最適化を取り返しのつかない一方通行にしません。

参考文献

• John L. Hennessy & David A. Patterson, Computer Architecture: A Quantitative Approach.
• John L. Hennessy & David A. Patterson, Computer Organization and Design.
• Gene Amdahl, “Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities” (1967).
• Hennessy & Patterson, “A New Golden Age for Computer Architecture” (ACM Turing Lecture).

もしこのような投稿をさらに読みたいなら、/blog をご覧ください。