後藤弘茂のWeekly海外ニュース
サーバーからモバイルまでカバーしつつコアを小さく抑えた「Cortex-A72」
（2015/5/29 06:00）
コアサイズを小さく留めるARMの現在のCPUコア戦略
ARMは、サーバー市場でIntelに挑もうとしている。同社の設計したCPUコアIPで、Intelの高性能CPUコアと勝負する。同社がこうした方針を打ち出している背景には、新CPUコア「Cortex-A72」と、半導体ファウンドリの3DトランジスタFinFETプロセスがある。ファウンドリがFinFETプロセスで、Intelに追いつくタイミング。そこに、64-bitをサポートするARMv8アーキテクチャの第2世代CPUコアCortex-A72を投入しつつある。
Cortex-A72コアでARMが強調するのは、高い性能効率。電力またはダイ面積当たりの性能で、Intel Broadwell世代を遥か凌駕すると説明する。実際、Cortex-A72のCPUコアのダイエリアは、TSMC(Taiwan Semiconductor Manufacturing Company)の16FF+プロセス利用時にわずか1.15平方mm。約8平方mmと見られるIntelのBroadwellコアの5分の1のサイズだ。Cortex-A72のクアッドコアに2MBのL2キャッシュのモジュールで、ほぼBroadwellの1コアのサイズとなる。
PDF版はこちら
ARMはプロセスの微細化に合わせて、同社のCPUコアを大型化する道を取らなかった。アーキテクチャの拡張を慎重に行ない、極めて小さなコアサイズにまとめている。そのため、ARMのトップエンドのCPUコアのサイズは世代とともに小型化している。Cortex-A72は、同じ64-bitアーキテクチャの現世代Cortex-A57に対して同じプロセスでもダイエリアが10%程度小さくなる。これは、アーキテクチャ上の改良による。ARMが、ダイエリア当たりの性能を徹底して重視していることが分かる。
3命令デコードとなった最初のARMコア「Cortex-A15」のCPUコアは、28nmプロセスで1.5～2.6平方mm程度のサイズだった。同じ3命令デコードのCortex-A72は、16nmプロセスで1.15平方mmと一回り小型化している。64-bit世代で比べると、Samsungの20nmのCortex-A57は2平方mm程度だったので、半分近いサイズに縮小した。
Cortex-A72のコアサイズは、実際、28nmプロセスでのCortex-A9のサイズに等しい。キャッシュを含めたCortex-A72クアッドコアモジュールのサイズは、40nm世代のCortex-A9のデュアルコアに近い。ARMは明らかに、CPUコアのサイズを大きくするのではなく、CPUコアの数を増やす方向へと向かっている。
そのためか、Cortex-A72の位置付けは、従来のARMハイエンドCPUコアとは若干異なっている。例えば、モバイルSoC(System on a Chip)最大手のQualcommは、同社のSnapdragonシリーズでは、ミッドレンジの「Snapdragon 620」にCortex-A72を採用。ハイエンドの「Snapdragon 820」には、ARMからのアーキテクチャルライセンスを受けて自社でマイクロアーキテクチャを開発した「Kryo」CPUコアを採用する。Qualcommは、明らかにCortex-A72より高性能なCPUコアを指向していると見られる。
第2世代となりこなれたARMv8 64-bitアーキテクチャ実装
Cortex-A57はARMにとって、最初のARMv8を実装した64-bit CPUだった。言ってみれば、Cortex-A57は64-bitの習作であり、ARMv8の普及のための地均し役だ。それに対して、Cortex-A72は、Cortex-A57から時間をかけて再設計したコアIPであり、ARMv8の第2世代として、よりチューンされたCPUコアとなっている。
Cortex-A72はCortex-A57に対して、同じプロセス技術であっても、マイクロアーキテクチャ上の改良によって性能が最大35%向上する。動作周波数は、Cortex-A57より若干上がり、16FF+プロセスで、スマートフォンの電力枠の中で2.5GHzをターゲットとしている。28nmプロセスのCortex-A15と比較すると、同じワークロードで75%低い電力消費となるとARMは説明する。20nmのCortex-A57と比較しても、大幅にワークロード当たりの電力消費が下がる。
このように、Cortex-A72はFinFETプロセスも手伝って、28nm世代のCortex-A15や20nm世代のCortex-A57から性能効率がジャンプする。そうした性能向上を背景に、サーバー市場やネットワーキングインフラストラクチャ市場を狙う。
しかし、ARMの提供するCPUコアIPは、汎用に広い用途を前提としており、ARMの伝統的な市場であるモバイル市場を中心ターゲットとしている点はCortex-A72でも変わらない。そのため、電力枠はコア当たり2.5W程度と低く設定して設計している。2.5WはCPUコア単体でTSMC 16nm FF+での数字で、リーク電流(Leakage)成分も含んでいる。Cortex-A72の性能は、あくまでも低電力CPUの枠内にある。
ARMは、サーバーだけに特化したCPUコアIPは、自社では開発していない。IPビジネスを行なうARMは、ニーズの高い市場にフォーカスしているためだ。サーバーに特化した高シングルスレッド性能コアは、ARMからアーキテクチャルライセンスを受けたベンダーによる開発を期待している。サーバー向けCPUの経験が深いAMDが開発中の高性能ARMコア「K12」などが、その一例だ。
そのため、Cortex-A72がターゲットとするのは、あくまでも、超低電力で高密度なデンスサーバーの領域となる。ARMが提案しているのは、アーキテクチャルライセンスで独自CPUコアを開発できる企業だけでなく、ライセンスコアを使う企業であっても、サーバーやネットワーク市場に参入できるということだ。
Cortex-A72アーキテクチャについては、概要を既にレポートしてあるが、より詳細を見て行くと、拡張ポイントがどこにあるのかがよく見えてくる。
スモール分岐に最適化した分岐予測機構
Cortex-A72の設計を主導したMike Filippo氏(Lead Architect and ARM Fellow)は、分岐予測(Branch Prediction)機構がCortex-A72の重要な拡張ポイントだと説明する。「Cortex-A57の分岐予測機構を、Cortex-A72では上から下まで完全に再設計し直した。その結果、Cortex-A57の分岐予測と比べると、大幅に性能が上がり、ユニット自体の電力消費も下がった」。
Cortex-A72のBTB(Branch Target Buffer)では、ARMは近い範囲へと分岐するスモール分岐(small banch)への最適化を行なって、BTBの効率を高めている。Cortex-A72のBTBのサイズは、2Kエントリだが、これはラージ分岐の分岐ターゲットをバッファした場合だ。Cortex-A72ではBTBエントリを分割することで、スモール分岐の分岐ターゲットなら、倍の4Kエントリ分ストアできるようにしている。
「我々は、スモールオフセット分岐への最適化を導入した。分岐には近い分岐(near branch)と遠い分岐(far branch)があるが、現実には多くの分岐がごく近い範囲で分岐する。そこで、Cortex-A72では、近い分岐の場合に、BTBには最大4,000のスモール分岐(アドレス)をストアできるようにした」(Filippo氏)。
多くのアプリケーションでは、分岐のほとんどはスモール分岐となるため、この改良は、リソースを増やさずに分岐予測精度を高め、結果として電力効率を高めることになるという。特に、モバイルではこの拡張は有効である場合が多いと見られる。
分岐予測機構をオフすることで電力をセーブ
Cortex-A72は64エントリと小容量のマイクロBTB(micro-BTB)も備える。命令やデータのL1キャッシュと同様に、分岐の多くはマイクロBTBにヒットする。そのため、大容量で電力消費の多いメインBTBを常に稼働させる必要がない。
Cortex-A72はCortex-A57と同様に、16byteの命令ウインドウで分岐予測をオペレートしている。しかし、分岐命令間に挟まれたベーシックブロックのサイズは、16byteを越える場合も多い。Cortex-A72では、そうした分岐命令のない命令ウインドウを事前に検知、大きなベーシックブロック内に収まっている16byteウインドウの中では、分岐予測機能をオフしてムダを減らす機能も加えた。これまでは全ウインドウ毎に予測を行なっていたが、Cortex-A72では不要なウインドウでは予測を行なわなくなった。こうした改良の結果、分岐予測機構全体の電力を下げることに成功したという。
ちなみに、Cortex-A72はサーバー市場もターゲットとしているが、サーバーワークロードに特化した分岐予測機能の強化は行なわなかったという。「ハイエンドモバイルのワークロードは、サーバーと似ている。ハイエンドモバイルでは、キャッシュとTLBと分岐予測に負担が掛かる。これは、サーバーも同様だ。そのため、ハイエンドモバイルに最適化した設計を行なえば、サーバーにも適用できる」(Filippo氏)。
また、ARMは、Cortex-A15以来、Cortex-A12/17も含めて「bi-mode(バイモード)プレディクタ」を採用して来たが、Cortex-A72ではbi-modeアルゴリズムを採用しなかった。
PDF版はこちら
マクロオペレーションを挟み込んだ新しいフロントエンド
Cortex-A57では、ARMのアーキテクチャ命令(Instruction)は、命令デコーダによって、内部命令である「マイクロオペレーション(micro-OP:uOP)」に変換、実行ユニットは、変換済みのuOPを実行していた。しかし、Cortex-A72では命令デコーダは、アーキテクチャ命令(Instruction)から、複合内部命令である「マクロオペレーション(macro-OP)」に変換される仕組みが加わった。macro-OPはディスパッチステージで、実行ユニットが実行できるuOPに分解される。
従来のCortex-A57では、命令デコーダは各サイクル最大で3個のuOPsを生成し、ディスパッチユニットが最大3個のuOPsを実行ユニットのキューに発行する。3 ARM命令デコードで3 uOPsディスパッチだ。問題は、1個のARM命令から、複数のuOPsが生成されるケースがあることだ。
Cortex-A57までは、1個のARM命令から複数のuOPsが生成される場合でも、個々のデコーダが1サイクルに1個のuOPしかディスパッチステージに送ることができなかった。そのため、2個のuOPを生成する場合には、命令デコードに2サイクルが必要だった。3個のデコーダが、各サイクルに3個のuOPsを送り出す仕組みで、ディスパッチャからキューへも3 uOPs/サイクルだった。デコードからディスパッチ、イシューキューへの帯域が狭いため、複数のuOPsになる複合ARM命令の場合は、ディスパッチ効率が落ちていた。
それに対して、Cortex-A72では、命令デコーダが各サイクル最大で3個のARMアーキテクチャル命令をデコードする点は同じだが、その後が異なる。命令デコーダは最大5個のuOPsを各サイクルに生成できる。実際には、複数のuOPsは、1個のmacro-OPに統合され、ディスパッチステージに送られる。ディスパッチステージへの帯域は、3 macro-OPs/サイクルとなっている。
PDF版はこちら
Cortex-A72では、デコーダが変換した複数のuOPを含むmacro-OPは、ディスパッチユニットがuOPsに分解(crack)する。ディスパッチユニットは、最大5個のuOPsを実行ユニットのキューに発行できる。つまり、各サイクルにつき、最大で3 ARM命令→3 macro-OPs→5 uOPsの帯域となる。3命令デコードで5命令ディスパッチフロントエンドだ。ちなみに、Cortex-A72のソフトウェアオプティマイーゼーションガイドでは、macro-OPとuOPのどちらも区別無くuOPとされているが、ARMのMike Filippo氏は、厳密には区別していると語っていた。
ARM命令からuOPsへの分解レートは8%程度
もっとも、実際にはほとんどのARM命令は、シンプルなuOPに1対1で変換される。Cortex-A72でも平均のクラッキングレート(命令を分解できる比率)は10%以下で、通常のコードでは8%程度だとARMのMike Filippo氏は言う。つまり、Cortex-A72でも、複合命令のmacro-OPsにデコードされる比率は8%程度に留まる。言い換えれば、ARMのアーキテクチャル命令は、平均で1.08倍のuOPsに変換される。
ちなみに、CISC系CPUも、複合命令をmacro-OPsに変換して、実行時にuOPsに変換するが、その場合は複合命令自体が多いのでよりクラッキングレートが高くなる。ARMアーキテクチャでは、CISCほど劇的な効果はないが、CISC型のアプローチを取って効率を上げているところが興味深い。
それに対して、Cortex-A72では、各サイクル最大3個の複合命令のmacro-OPとして、それぞれ複数のuOPsをまとめてディスパッチャーに送ることができる。ディスパッチステージからは、最大5個のuOPsを各サイクルにディスパッチできる。
もっとも、5 uOPs/サイクルは、あくまでもピークのディスパッチ帯域で、平均のディスパッチレートはそれよりも低くなる。既に述べたように、Cortex-A72では、ディスパッチステージが発行できるuOPs数は、Cortex-A57世代より平均1.08倍に向上するだけだ。それだけを見ると、劇的なレート向上ではない。しかし、従来は命令デコードに2サイクルかかっていた複合命令のデコードが1サイクルで済むようになったため、より高い命令デコード効率となり、性能向上に寄与している。
ちなみに、ARM命令では典型的な複合命令として、シフト命令とALU命令が複合したシフト-ALU命令がある。しかし、こうしたARM特有のアーキテクチャル複合命令の一部は、実行時に2個のuOPsには分解されない。Filippo氏によると、シフト-ALU命令の場合は1個のuOPとして、マルチサイクルクラスタに発行される。マルチサイクルクラスタには、シフト-ALUのパイプライン型実行ユニットがあり、2サイクルレイテンシでシフトプラスALUを実行する。
これは、実行パイプラインを複合命令に合わせて設計して、そのままuOPとして実行した方が効率がいいという判断だ。ARMの従来のアセンブラコーディングでは、よく、効率を上げるためにシフト-ALUを使う場合があるが、Cortex-A72のパイプラインでも、シフト-ALUは効率が上がることになる。
しかし、同じARMの複合命令でも、マルチプルロードまたはストアのようなタイプの命令は、一旦1個のmacro-OPにデコードされ、後段で複数のuOPに変換されるようだ。このように、ARMの複合命令の種類によって複合macro-OPになるかどうかは異なっている。この他に、ARMはARMv8の64-bitアーキテクチャ「AArch64」命令で、アーキテクチャ命令同士を融合させて1つの融合内部命令(フューズドMicro-OPs)にするインストラクションフュージョンをサポートしている。
命令デコードではループバッファを削減
デコード&リネームステージでは、Cortex-A57に実装されていた「ループバッファ(Loop Buffer)」がCortex-A72ではなくなっている。ループバッファは、デコードしたuOPsをキャッシュするバッファだ。ループで同じ命令を繰り返す場合に、ループバッファにキャッシュしたuOPsを読み出す。アーキテクチャ命令からuOPsへの変換のロスをなくすためのものバッファだ。
ループバッファはCISC(Complex Instruction Set Computer)では一般的だが、ARMマイクロアーキテクチャでも、Cortex-A57には32エントリのループバッファがあった。しかし、Cortex-A72では、このバッファは、削除された。実際には、Cortex-A72も、非常に小容量のバッファは依然として持っているが、32エントリの相対的に大きなバッファは採用されなかったという。Cortex-A57で、実装してみたものの、電力効率の面で、あまり有用ではなかったからだと言う。
可変長命令のCISCのx86系CPUでは、可変長ゆえにデコードが重いため、ループバッファが重要となっている。しかし、ほぼ固定長のARM系ではデコード負荷がそれほど高くないため、こうしたアーキテクチャ選択になったものと推測される。