ARMはロンドンにて4月23日(英国時間)、同社が今年2月に発表した「Cortex-A72」について、さらに詳細を発表したので、この内容をお届けしたい。
以前のレポートの中で、Cortex-A72が基本的にはCortex-A57と同じ構造であること、Cortex-A15比で最大3.5倍、Cortex-A57比でも最大1.8倍もの性能が出るとご紹介したが、その内容というか理由は明らかではなかった。今回はそうした詳細が明らかにされた形だ。
まずOverallの話で言えば、対Cortex-A15比では最大3.5倍高性能、あるいは同じ処理性能であれば75%の省電力という話が改めて紹介された(Photo01)。またTSMCの16nm FF+に対応したPOP IPが用意され、さらに当初からCCI-500との接続が念頭に置かれているとする。
では3.5倍の根拠は? というのがこちら(Photo02)。仮に動作周波数を同じ1.6GHzとした場合は、Cortex-A72が2.24倍ほど高速、という計算になる。ちなみにこのプロセスノードの違いがどう消費電力に影響するかという比較がこちら(Photo03)。28nmプロセスのままでCortex-A57/Cortex-A72を製造した場合でも、Cortex-A57で40%ほど、Cortex-A72では50%消費電力を下げられる。この結果としてその分動作周波数を上げられる訳だが、さらにプロセスノードを変更することで消費電力を大きく落とせることが判る。
Cortex-A72のもう1つの特徴は、当初からMobile以外の用途を考慮していることだろう(Photo04)。これはCortex-A57でも同じだが、ECCの搭載や大規模クロスバーの採用などサーバにも適した特徴を備えており、さらにはADAS向けなどの用途も念頭においているとする。
さて、ここからはInternalの話である。この図そのものは、すでにARMのWebサイトにも掲載されているものである。まずフロントエンドのFetch/BPU(Branch Prediction Unit)の話。この段階では3つのARM命令(32bit/64bit)を1cycleで取り込む形になる。実はこの時点で分岐予測に関してかなり色々な処理をやっているらしく、分岐予測の精度を上げると共に不要な分岐予測のアクセスを抑制するとしている。またTLBやμBTB(Branch Target Buffer)の構造をCortex-A57から変更、効率を改善したとしている。またこれらのバッファはいずれもPower-optimized SRAMを利用しているとの事だ。
Photo05:このレベルの図だと、Cortex-A72との違いすらさっぱり判らない |
Photo06:そうなるとどういう分岐予測メカニズムを採用したのか聞きたいところだが、後で確認しても「色々やっている」と詳しくは教えてくれなかった |
次がDecode/Renameであるが、Cortex-A57はMicroOps構造を取っており、通常のARM命令3つを最大5つのMicroOpsに変換するとする。また64bit命令の一部についてはInstruction-fusion(Intelで言うところのMacro Ops Fusion)を利用することが可能だとか。ただ後で確認したら、これは64bit命令だけではなく32bit命令でも行われているとのことだった。また機能的にはSIMD/FP周りの新命令が追加されたとしている。加えて、一般論としてプロセッサコアで一番消費電力が大きいのがDecode段(最近だとAVXのように256bit幅のSIMDとかがフルにうごくとこちらも馬鹿にならないが、そうした例外を除くとDecode段が一番消費電力が大きい)ということもあって、色々な省電力機構を実装したとしている。
さて、次がDispatch(Photo08)。先に書いたとおり、3つのARM命令が5つのMicroOpsの形で実行されることになり、これによる効率改善がCortex-A57からの大きな性能ブーストの一因と思われる。ただここでも細かく無駄を省くことで、性能改善と省電力化を両立したとしている。
さて、いよいよ実行ユニットである。Photo09では5つの実行ユニットが並んでいるが、実際は
- Single Cycle ALU:2ポート
- Branch:1ポート
- Multi Cycle ALU:1ポート
- NEON/FPU:2ポート
- Load/Store:2ポート(Load×1、Store×1)
という構成になっている。ちなみに各々の実行ユニットのLatencyも大幅に改善されており、例えばFADDは4cycle→3cycle、FMULは5cycle→3cycleなので、FMAC(Multiply and Add)では9cycle→6cycleになる計算だ。ALUについても細かく性能改善が行われており、トータルで性能改善とあわせて省電力化が進められたとする。
Photo09:ある実行ユニットの結果をそのまま利用して次の計算を行う(FMACなど)ケースで、Latencyを0にした(Multiple zero-cycle forwarding datapaths)というあたりも地味に性能改善に繋がると思われる |
Load/Store UnitとL2に関しても性能改善が図られており、特に性能を落とさずに省電力化がずいぶん進められたとする(Photo10)。またL2は共有になる関係で、効率改善のためにあえてHigh-Bandwidth向けのTuningが施されたとの事だ。また共有L2キャッシュにおいてキャッシュコヒーレンシを管理するACP(Acclerator coherene port)も作り直されたとの事である(Photo11)。