大原雄介の半導体業界こぼれ話
CPU処理性能向上の歴史というか、苦闘の歴史
2024年1月30日 06:21
特別企画を書いていてしみじみ思ったのだが、本当に最近は性能向上の方法論が尽きて来た感が強い。そこでちょっとこのコラムでは振り返ってみようと思う。
命令数を増やすことで高性能化(4004～80386)
Intel 4004では総トランジスタ数が約2,300(嶋正利氏の回顧録によれば2,237個)だったが、そもそも設計時点では2,000個以内に収めるような指示があったらしい。なんでこんなに厳しかったか? といえば、当時の半導体製造技術が(今と比べると)未熟だった、ということに尽きる。
製造プロセスは10μmで、ダイサイズはおおよそ4mm×3mmの12平方mm(写真1)。当時はまだ直径50mm(というか2インチ)のウェハで製造しており(写真2)、理論上はこの50mmウェハ1枚で130個程製品が取れることになる。ただ当時は製造歩留まりも低かったから、100個取れるかどうか、というあたり。当時のウェハ製造コストは公開されていないが、こんなグラフがあり(図3)、1971年当時だとトランジスタ1個の価格は0.3ドル。つまり4004の製造原価は700ドルをちょっと切るぐらいということになる。
ちなみにIntelは当初これを60ドルで販売したので、売れば売るほど赤字になるわけだが、後継の4040が登場した1974年にはトランジスタ1個あたりのコストは0.07ドル、つまり161ドルまで製造コストが下がっており、1976年にはトランジスタ1個あたり0.015ドルで製造コストは35ドルを切るところまで行っている。なのでまぁ長期的に作ればもちろん利益が出るわけだが、Intelの経営陣がこれをどの程度見通していたかは定かではない。
ただとりあえずは赤字でもいいからマーケットを立ち上げないとその先のビジネスにつながらないとはいえ、赤字幅を抑えたいのは当然である。2,000個以内というのは製造原価600ドル以下という話で、とはいえ4004はこれを守り切れなかったわけだが、そんなわけで初期のCPUの場合、製造コストとか歩留まりの問題があって、大規模な回路を入れられなかった、という話が最初にある。
またウェハも当初は50mmで、次いで75mm/100mm/150mmとだんだん大型化していくが、そうは言ってもではいきなり100平方mmのダイのCPUを製造するのは無理がある。1974年の8080が6μmプロセスで20.1平方mm、1978年の8086が3μmプロセスで32平方mmといった具合で、すこしずつダイサイズを増やしながら使えるトランジスタの数を増やしていった(8086だと29,000個だから4004の10倍強である)というあたりだ。要するにこの時代はまだ、いろいろ機能を盛り込もうとしても回路サイズ的に無理がある時代であり、なので盛り込みたい機能があっても見送られることが多かった。
この辺りを一切自重せずに設計をした結果大失敗したのが「iAPX 432」で、1975年から設計が始まって1981年にチップは完成したが、1チップで収めることができずに、命令デコーダの「iAPX 43201」(66.3平方mm)と命令実行の「iAPX 43202」(74平方mm)、それと周辺I/Oを司る「iAPX 43203」(75.3平方mm)というマルチチップ構成になってしまった(しかもここまで巨大なチップなのにメモリコントローラは非内蔵で、これは「iAPX 43205」が用意された)。
しかもiAPX 43201と43202の間の通信がボトルネックとなり、動作周波数は最大でも8MHz止まりとなった。結局採用事例はほとんどない(英語版のWikipediaに、iAPX 432を搭載したSBC:Single Board Computerの画像が上がっており、Intel自身がSBCの形で最低100セットあまりを販売したのは確実である)まま消えてしまっている。要するに当時の半導体製造技術では、大きくて複雑なCPUを製造するのはまだ困難だったわけだ。
1980年台まではそんなわけで、使えるトランジスタ数を少しずつ増やしながら、それに伴い少しずつ機能や命令を増やして性能を向上させる、という方向性であった。これの最後の世代がIntelの「80386」とかMotorola「MC68020」あたりになるかと思う。32bit化や仮想記憶のサポートなどにトランジスタが割かれ、その一方で命令処理そのものは非パイプライン構造のままだし、命令処理ユニットも1個だけだった、という時代である。
IPC≧1を狙う時代へ(80486～Pentium III)
この方向性が変わってきたのは、多分1980年台後半である。命令セットの32bit化や仮想記憶を含む本格OSへの対応、これに伴うセキュリティ(というかPrivilege)の実装などが一段落し、にも拘わらず利用できるトランジスタの方は微細化に伴い多少ゆとりができた。あくまでも「多少」のレベルで、ドラスティックに回路規模を大型化するには至らないが、これまでとは違った設計が取れるようになった。
Intelの「80486」やMotorolaの「MC68030」はキャッシュをチップ内に内蔵。80486はさらにデコーダをマイクロコードからハードワイヤードに変更するなどして、スループットを大幅に強化した。いわゆるMIPS値で言えば、80386は33MHzの動作周波数のものは11.4MIPS程度で、つまり1命令の実行に平均3サイクルを擁していたのが、80486では25MHzのものが20MIPS、つまり1命令あたり1.25サイクルまで短縮している。
この時期はまたRISCプロセッサの興隆が起きた頃でもある。商用製品で言ってもMIPS R2000やR3000、富士通やTIなど各社で生産されたSPARCやmicroSPARC、IBMのPOWERなどが先駆け(*1)になったわけだが、これらは基本1命令が1サイクルで処理できることが前提(怪しいものもあるが)で、それを可能にするシンプルな命令セットを備えたことで、コード密度はやや下がったものの、動作周波数の高さでこれを補うことが可能になった。
ちなみにMC68030はMC68020とプロセッサの構成が基本同じということもあり、それほどIPCの向上が見られていない(MC68020が2.8MIPS@20MHz、MC68030が3.3MIPS@20MHz)。ただこれに続くMC68040では処理のパイプライン化が図られたことで、44MIPS@40MHzを達成している。
ただこの命令パイプラインの高速化は、どんなに頑張っても1MIPS@1MHzが理論限界である。当たり前の話で、1本のパイプラインは同時に1つの命令しか処理できない。そして同期回路(クロックに合わせて内部回路が動作するデジタル回路)では、レイテンシはともかくとしてスループットは1以上になりようがないからだ。
ではMC68040はどうやって1.1MIPS@1MHzを実現できたかというと、命令パイプラインを複数(MC68040なら2つ)搭載している。いわゆるスーパースカラーと呼ばれる方式だ(図4)。IntelもPentium世代でこのスーパースカラーを搭載、188MIPS@100MHzを実現している。RISCプロセッサも当然これに倣い、スーパースカラーを搭載した製品(UltraSPARCとかMIPS R10000)を投入することで、IPCを1以上に引き上げることに成功している。
ではスーパースカラーをどんどん発展させていけば性能は上がるか? というと、命令の依存性(命令の前後関係に依存して、同時に発行できる命令が限られる)の制約がある。これを多少なりとも解消するものとしてアウトオブオーダーが、まずIntelのPentium Pro、次いでAMDのK6(というか旧NexGenのNx686)などで実装され、RISCプロセッサもこれを導入してゆく。
ついでに言えばこのアウトオブオーダーと併せて導入されたものに、CISC命令のRISC変換が挙げられる。Pentium ProとかNx686/K6、内部はRISCプロセッサとして実装されており、フロントエンドのデコーダでx86命令を独自のRISC命令(当初これをRISC86だのなんだのと名称を付けるのが流行ったが、もう最近はMicroOpとかと呼ぶのが一般的である)に変換することで、構造の簡素化やパイプラインの高速化が可能になった。
この後、AMDはK7、IntelはPentium II/IIIとこれを進化させてゆくと共にSIMD系の演算をサポートしてゆくが、SIMDはデータ処理性能向上にはつながってもIPCの向上には無縁なのでここでは措いておく。
高動作周波数チャレンジの失敗とマルチコア化(Pentium 4～Core 2)
ではこれに続く世代は、さらにパイプラインを増やして性能を引き上げるか? というとそっちには行かなかった。ポラックの法則というかポラックの経験則(Pollack's Rule)と呼ばれるが、「プロセッサの性能はその複雑性の平方根に比例する」というものが性能を支配している(図5)ためだ。
パイプラインを増やせば増やすほどエリアサイズも増えていくが、性能はその平方根でしか伸びない、というものである。つまりダイサイズを2倍にしても、性能は1.4倍にしかならない。これはトランジスタの使い方として不効率である。
まず最初に考えられたのは、動作周波数を引き上げることだ。IntelはこれをPentium 4として実装するが、ご存じの通り5GHzを目指しつつも実際には4GHzにも届かなかった。90nmプロセスでリークが多くなりすぎ、まともに動かなかったのが原因であり、これに一応の対策を施した65nmでもまだ高速動作は覚束ない。
結果、IntelはTejasと呼ばれていたコアをキャンセルすることになり、その代わりにマルチコアに舵を切る。
Pollack's Ruleは、1つのコア内の複雑性に目を向けたものだが、そもそもコアを2つにすれば「運が良ければ」2倍の処理性能が発揮できる。2倍のサイズのコアでも1.4倍にしかならないなら、コアの数を増やした方がお得、というわけだ。
AMDはAthlon 64コアで当初からDual Coreを念頭に置いた周辺回路を用意し、2005年にはDual CoreとしたAthlon 64 X2を導入。IntelもPentium Dと呼ばれる2つのダイをMCM構成とした製品を2005年から導入、さらに2006年には1ダイに2コアを内蔵したCore 2 Duoと、これを2ダイ構成にしたCore 2 Quadを投入する。少なくとも見かけ上はこれでコアの数だけ性能が上がるわけで、あとはどうやってすべてのコアに仕事をさせるか、というチャレンジになってきたわけだ。
ちなみにこの高動作周波数チャレンジとマルチコア化が激化するなか、ほとんどのRISCプロセッサは市場をなくして敗退してゆき、残ったのはArm(当時の表記ではARM)のみという感じになってきた(POWERを除く)。
アムダールの法則と、再びIPCの向上へ(Core iとZen)
ではコアの数を増やせば増やすほど有利か、というとそうは問屋が卸さない。こちらはこちらで有名なアムダールの法則がそびえ立っている。アムダールの法則は以下のように定義されているが、
ここで
- Slatency:全体の性能向上率
- p:全体の処理のうち並行動作できる割合
- s:並行動作できる部分の性能向上率
となっている。
たとえば4コアのCPUであるプログラムの処理を行なうが、そのうち並行して動作可能な部分は全体の30%だとすると、全体の効率は1÷((1-0.3)+0.3÷4)=1.2903……で29%しか高速化しない、というものだ。要するにいくらコアの数を増やしても、処理がシーケンシャルだと意味がないという話である。
Excelだったら、複数のセルの同時更新を行なう際に処理を分割できるから高速化が実感できるが、Wordで文章を打っている際には同時処理もへったくりもないから、性能向上は望めないというわけだ。
そこでこの時期IntelやAMDは積極的にソフトウェアベンダー(主にMicrosoftだが、それ以外にも)に声を掛けて、何とかアプリケーションのマルチスレッド対応を増やそうと努力している。その甲斐あって(?)、Windowsがだんだん重くなってきたのは別に偶然ではない気がする。
コア数の増加は現在も続いており、コンシューマ向けに64コアの製品が実際に投入されたりしているわけだが、それと並行して再びIPCの向上に取り組む格好になってきた。Intelで言えばSandy Bridgeの世代がこれで、バックエンドの処理パイプラインを大幅に強化している。ただIntelは22nmプロセスまでは順調だったものの、その後の14nmと続く10nm世代で導入に失敗することでちょっとけつまずいた。
そもそもIPCの向上=パイプラインの強化は、プロセス微細化に伴い利用できるトランジスタ数が増えるので、この増える分を充てる形で実装してきたから、プロセスの導入に失敗したらパイプラインを増やすための原資を欠くことになる。結果、この時代Intelは(ダイサイズ肥大化に目をつむって)コアの数だけを増やすことで対処せざるを得ず、無駄にコア数が増えることになった。
一方のAMDはBulldozerコアで大失敗してしばらく虫の息状態が続くものの、2017年にZenコアで何とか復活。IntelのCore iに負けないペースでコア数とIPCを強化していき、現在に続く形だ。
ヘテロジニアスコンピューティングの時代?
こうした性能向上のための技術の中で、それこそ90年台から言われ続けていながら、いまだに本格的に普及しているとは言えないのがヘテロジニアスコンピューティング、あるいはヘテロジニアスマルチコアである。要するにCPUはどんな処理にでもそれなりの性能が期待できるが、ある特定の処理に特化した高速化という機能は原則搭載されていない。
例外がSIMD系の拡張命令で、MMX/3DNow! /SSE/AVXと次第に進化、最近はAMXも仲間に入ったが、これは特定の処理を本当に高速化できる。MMXとか3DNow! の時代は、当時問題になっていたJPEGとかMPEGのデコードを高速化する、というためのもので、要するに命令処理性能よりもデータ処理性能が重視される用途向けのものだった。実はこれは現在も変わっておらず、命令処理性能が重視される用途には引き続きCPUに頑張ってもらい、データ処理性能が問題になる用途に追加のアクセラレータを入れる、という格好である。
さてヘテロジニアスコンピューティングという言葉は1990年台から言われていたが、具体的にそのターゲットが湧いてきたのは2000年台後半あたりである。要するにGPUだ。特に熱心だったのがAMDで、当時同社は爆死したBulldozerコアの性能ギャップを少しでも埋めるため、GPUを利用したヘテロジニアスコンピューティングを利用したAPUの実現に向け、大車輪でハードウェアとソフトウェアの両面から実装を進める。
ハードウェアの面では、第一世代では単なるCPUとGPUが内部的にPCI Expressでつながってるだけの構造だったが、そこから少しずつキャッシュコヒーレンシを持つバスで両者を接続するように進化させてゆく。
ソフトウェアの面では、HSA(Heterogeneous System Architecture)という用語を掲げ、この下でOpenCLによるアプリケーションインターフェイスの統合化を進める。最終的にこのHSAはどうなったか? という話はたとえばこれにまとまっているが、Zenが登場するまでの時間稼ぎだったと言われても仕方がない扱いになってしまっているのはまぁ当然かもしれない。とはいえ未だにOpenCLを使うことはできるから無駄になったわけではないのだが。
NVIDIAはこれに先駆けてCUDAを広範に提供しているが、同社の場合GPUのみの提供(モバイル向けにはTegra APX 2500が2008年から提供されているが、クライアント向けにはいまだにCPUを提供していない:チップセットビジネスも2010年に撤退した)ということもあり、CPUのアクセラレータとしてGPUを使うというよりは、GPUが処理のメインであり、CPUはその補助といった扱いに近い感じもあって、ヘテロジニアスコンピューティングとはちょっと意味合いが違う。
NVIDIAは現在、特にHPCの分野でArmベースのCPUコアとGPUを一つのパッケージに収めたGH200を投入、ヘテロジニアスコンピューティングのプラットフォームはこのArm CPU+NVIDIA GPUをコアに進める予定だ。
一番出遅れたのがIntelだった。同社の場合、CPUがあまりにそれまで強すぎたという事も理由の1つにはあるかと思う。2013年にブライアン・クルザニッチ氏がCEOに就任後、同社は突如としてさまざまなCPU以外のリソースを買い漁り始める。
特にAIに関しては2016年にNervana Systemsを買収し、1カ月後にMovidiusを買収し、3年後にはHabana Labsを買収し、といろいろ買いこんでいる一方でNervana Systemsは事実上放棄するなどいろいろと不手際は目立つ。どうせならGPUもそれこそImagination Technologiesでも買収すればよかったと思うのだが、それをせずに代わりにAMDからRaja Koduri氏を2017年に招聘し、そこから改めてGPUを構築する。
ついでに言えば(最近別会社になったので今後はサポート対象から外れそうだが)Alteraも買収していた。こうしたものを全部統合するためのものとしてoneAPIと呼ばれる巨大なフレームワークを打ち立てている。
ヘテロジニアスコンピューティングはうまくいくのか
そんな感じで各社とも一応ヘテロジニアスコンピューティングに向けたプラットフォームを用意はしているのだが、さてこれうまく行くだろうか? というのが今月のお題。結論から先に言えば「無理じゃね?」と筆者は考える。理由は、各社のソリューションに互換性がないからだ。
IntelはoneAPIで全部カバーするとか言っているが、oneAPIそのものが巨大な継ぎはぎというか、本来関係ないものを全部oneAPIという名称で統合しているように見せかけているだけ、というのが実情である。そもそもoneAPIの最初のビジョンは、1つのAPIで全てのCompute Resourceを画一的に扱えるようにするはずだったのが、現状でも
- oneDPL(oneAPI DPC++ Library)
- oneMKL(oneAPI Math Kernel Library)
- oneDAL(oneAPI Data Analytics Library)
- oneDNN(oneAPI Deep Neural Network Library)
- oneCCL(oneAPI Collective Communications Library)
- oneTBB(oneAPI Threading Building Blocks)
- oneVP(oneAPI Video Processing Library)
と7種類ものoneAPIライブラリがあるうえ、これとは別にOpenVINOをAI推論向けに推進。さらに言えば旧Habana Labsの製品群は、未だにoneAPIでサポートされていない。
それでもこれがマルチプラットフォーム、つまりAMDやNVIDIAのGPUとかAMDのNPUなども全部カバーする、と言えばまだ救いがあるのだが、もちろんそんな話はない。
AMDはもうちょっと話が複雑である。昨年(2023年)5月にIEEEのFCCM23(Field-Programmable Custom Computing Machines)が開催されたが、その際のスライドがこちら(図7)。oneAPIのようなカバーを被せるのは非現実的であり、アプリケーションをMLIR(Multi-Level Intermediate Representation)ベースで記述して、そこからLLVM/ROCm/MLIR-AIE/CIRCTを介してCPUなりアクセラレータに処理を割り振るというストーリーである。
一見するとこれはかなり自由度が高く、マルチベンダー対応も容易に見えるが、図7で言う赤い部分を、たとえばNVIDIAとかIntelが自社のGPUあるいはNPU用に提供するか? というと短期的にはあり得ない感じがするし、そもそもアプリケーションをMLIRで記述する時点でハードルが高い。
あとFPGAのプログラミングにCIRCTを使うというのも、意図としては判らなくもないのだが、現状AMDのFPGA Fabricの利用にVivado/VITISが使われていることを考えると、何か移行用のツールがないと難しい(というか、CIRCTでVITIS並みの性能が出るコードを吐けるのだろうか?)ように思える。
もう少し一般的な話で言えば、現状AMDはGPU向けのライブラリはROCmに絞ってこれに全力を注いでいる状況で、もちろんRadeonでもROCmは利用可能だが、NVIDIAやIntelのGPUは当然対象外である(それでも以前はWindowsが対象外だったのが、昨年からWindowsもサポート対象に加わったのは喜ばしいが)。
AIに関してはGPUを使うならROCm、CPUでやるならZenDNN、NPUを使うならONNXベースのRyzen AI Softwareを使う格好となる。2022年のFinancial Analyst Dayにおけるロードマップ(図8)では、クライアントも含めてぼちぼちUnified AI Stack 2.0がリリースされる予定なのだが、今のところ具体的な登場時期などは明らかにされていない。で、これを見る限りはやっぱりAMDも自社のハードウェアのことしか考えて居ない。NVIDIAは言うに及ばない。
この状況でヘテロジニアスコンピューティングが普及するというのは、つまりアプリケーション側がどんなプラットフォームで動いているのかを確認の上、IntelならoneAPIなりOpenVINOを、AMDならROCmなりUnified AI Stackなりを、NVIDIAならCUDAを使ってそれぞれ処理を行なうように記述しないといけない、ということである。
似た話はゲームの世界では既にある。いわゆる超解像で、NVIDIAのDLSSとAMDのFSR、IntelのXeSSの全部をゲームの中でサポートできるようにし、あとは動作環境に応じてそれぞれオプションを有効化/無効化するという格好だが、これと同じことをヘテロジニアスコンピューティングでもやらないといけないわけだ。そんな手間暇かけるアプリケーションは、果たしてどのくらいあるだろう? もちろんベンダー(つまりAMDやIntel、NVIDIA)がその対応コストを払ってくれるなら対応するかもしれないが、そんなコストを支払えるとも思えない。
多分OpenCLと同じように、複数ベンダーで画一的に利用できる共通のAPIを用意しない限り、アプリケーションベンダーは対応を嫌がるだろう。ただそうした共通APIはOpenCL同様、中途半端なものになりがちであり、仕様を策定したもののあまり使われずに消えてゆく羽目になりかねない。
この辺を考えると、ヘテロジニアスコンピューティングは本当に一部、それこそHPCとか組み込み向けなど、利用するコンポーネントを一意に定められる環境以外では普及しないように思われてならない。多分クライアント向けは引き続き、ヘテロジニアスコンピューティング以外の方法で高速化に向けた努力を続けるしかないのだろう。
(*1 ^)BerkleyのBerkley RISC、IBMのIBM 801とかROMP、ArconのARMなどほかにもいろいろあるが、挙げ始めるときりがないのでやめておく。