COMPUTEX TAIPEI初日にあたる5月30日、ARMは台北でプレスカンファレンスを開催し、ここで2017年のフラグシップモバイル機でVRを実現させるためのコンポーネント、という位置付けで「Cortex-A73」と「Mali-G71」を発表した。このCortex-A73について、もう少し詳しく説明を行いたいと思う。

Cortex-A73は、「Artemis」というコード名で知られていた製品である。Artemisそのものの話は以前、ちょっと触れたが、Cortex-A72の後継製品となる。

そのArtemisであるが、設計目標は純粋な性能というよりは、性能/消費電力比の改善にある。この理由を説明したのがこちら(Photo01)。big.LITTLE構成であっても、長時間利用していると発熱の問題が出てきてしまうため、結局big側のコアの動作周波数を落として運用せざるを得ず、これが性能に大きな影響(システムパフォーマンスで25%減)を与える、という説明である。つまりより高い性能は当然必要であるが、同時にCortex-A57やCortex-A72を上回る省電力性が必要、という判断である。

Photo01:これは実際のスマートフォンを利用して測定したそうだ

こうしたニーズにあわせる形で設計されたのがCortex-A73である(Photo02)。"Mobile Envelope"、つまりスマートフォンに納まる熱設計電力で最大2.8GHzまで到達でき、同一周波数なら30%の消費電力削減ができ、しかもエリアサイズはコアあたり0.65平方mmに過ぎない。「プレミアムCPUとしては史上最小のコア」がCortex-A73の謳い文句でもある。実際に製品に入るのは2017年になると思われるが、コアあたりの消費電力750mW、という枠の中で"Sustained"(連続利用可能な動作周波数)で従来比1.3~2.1倍、というのがCortex-A73の大きな特徴である。

Photo02:当然これはCortex-A73が10nm世代を利用した場合の数字である。また比較対照になるCortex-A72は16nm世代でのものである

Photo03:Peak、つまり一時的なブースト状態の動作周波数(とその時の性能)はもっと縮まるが、Cortex-A73はSustainedとPeakの差が小さいのも1つの特徴である。ただこれはライセンスを受けたベンダのインプリメント次第なところもある

ではこれをどう実現したのか、という内部の話がここからである。まずフロントエンドというか、パイプラインの前(Photo04)に関して言えば、命令フェッチをより高効率にすると共に、「bubble removal(スケジューラなどの都合で実行できない空きスロットを除去する)」に焦点を置いた事が説明されている。また分岐予測については、「BTAC(Branch Target Address Cache)」の拡大と共に、Micro-BTACを追加した事が明らかにされている(Photo05)。実はCortex-A57→Cortex-A72でも分岐予測まわりが随分拡充されている。分岐を「Far Branch」と「Near Branch」の2つに分け、Near Branchだと倍のサイズをBTB(Branch Target Buffer))に格納できる様にした他、より小容量ながら高速アクセスが可能なmicro BTBを搭載するなど工夫されていたが、Cortex-A73ではそれがBTACにまで及んだ形だ。ちなみにCortex-A72でもサーバ向けのワークロードに最適化した機構はあまり搭載されていないが、Cortex-A73ではこれがさらに徹底されている可能性が高い。

Photo04:Micro-OPs Fusionの類についても、これも従来同様に実施しているとの事。ただこれも、やはり性能の向上というよりは効率の改善の方向に向いているという話であった

Photo05:小規模なループなど煩雑に使われるものは、おそらくよりレイテンシの少ないmicro-BTACに格納することで効率を上げるという話の模様。micro-BTACの実装としてはTCMと同じように1サイクルでアクセスできる様になっているのではないかと思う

さて、デコード段(Photo06)であるが、ここがCortex-A73最大の特徴と言っても良い。Cortex-A57/A72はどちらも3-wayのデコーダ(正確に書けば、3 AArch32/64命令のデコーダ)を搭載していたが、Cortex-A73ではこれが2-wayになっている。変換の結果、Micro-OP(マイクロオペレーション)がいくつ生成されるかは明らかにされていない(Cortex-A72の場合は最大5つだった)が、Instruction-fusionなどの機能もあるから、2つということはなく最大3~4つというあたりではないかと思われる。普通に考えればデコーダのIssueを3-wayから2-wayにするとその分解釈できる命令数が減るわけで、IPCはむしろ下がる方向に進むわけだが、モバイル向けアプリケーションにおいてはかならずしも3-wayがフルには生かされておらず、なので2-wayでも効率よく実行できる仕組みを整えた事で実質的には若干とは言え性能が上がることになった、という訳だ。

Photo06:ここでも、いかに消費電力を下げるかの工夫がいろいろ施されている。AArch32とAArch64は以前も一部回路については共用されていたが、その範囲を広げたらしい