「Cortex-A」は“Solution-based”で性能改善、来るべきMatterhorn世代に向けて：Arm最新動向報告（7）（1/3 ページ）

⇒連載「Arm最新動向報告」バックナンバー

　今回の「Arm TechCon 2019」の場合、新規のIP製品という意味では「Ethos-N57/N37」と、これに合わせて「Mali-G57/Mali-D37」の発表があった程度だが^※）、厳密に言えばこれらの発表は2019年11月に入ってからだった。TechCon期間中の同年10月6〜8日はNDA条件下で開示されただけなので、その意味では新規のIP製品の発表はなかった、としてもいいことになる。

※）関連記事：AIやAR、VRを民生機器用デバイスへ搭載できる最新プロセッサIPを発表

　その代わりというのも何だが、アプリケーションプロセッサ向けのIP製品である「Cortex-A」（と恐らくは将来の「Neoverse」）における性能改善の方向性について紹介しよう。イベント初日のイアン・スマイス（Ian Smythe）氏の基調講演では、Cortex-Aについて、“Solution-based（ソリューションベース）”で性能改善を行っていくこと、セキュリティを強化すること、そしてソフトウェアを強化すること、という3つのテーマが示された（図1）。

図1　これら3つが重要、というのはもちろん基本だが、性能を引き上げるのに“Solution-based”を考慮しないといけない時代になった、という話でもある（クリックで拡大）

　逆順になるが、3つ目のソフトウェアの強化は、ゲームエンジン「Unity」のサポートである。Unityそのものは、もちろん現在のArmプロセッサ上で動作しているが、今回はArmとUnityがパートナーシップを締結。Unityが「Universal Render Pipeline」「DOTS（Data Oriented Tech Stack）」「AR Foundation」の3つについて、Arm向けに最適化したバージョンを提供することが明らかにされている。この他にも、AIフレームワーク「ArmNN」に対応する（Unityエンジン内からArmのNeural Processorの呼び出しを可能にする）という話もあり、これはこれで大きな出来事ではあるのだが、これはUnityとUnityを利用するアプリケーション開発者側の話。Arm側が、Unityに向けて何か新機能を搭載する、というわけではないのでちょっと割愛する。

　さて、あらためて1つ目である、Solution-basedなコンピューティング性能引き上げについて紹介しよう。IPC（クロック当たりの実行命令数）全体を引き上げる、というのは非常に困難なのはご存じの通り。そもそも「Cortex-A77」で6命令同時デコード／10命令同時発行のSuperScalar／Out-of-Orderを実装したばかりであり（図2）、これをさらに引き上げようとすると、より広帯域なL1キャッシュとデコーダーを実装し、実行ユニットの数も増やす必要がある。

図2　2019年6月の「COMPUTEX」で発表された際の資料。もちろんFetchの速度は6命令/cycleに満たないが、1.5KエントリのμOp Cacheからはピークで6命令/cycleのデコードが可能となる（クリックで拡大）

　もちろんDispatch Window（ディスパッチウィンドウ）の数も増やす必要もあるし、実行ユニットが多くなるとWrite Combining（ライトコンバイニング）も複雑化するので、LD/ST Queue（ロード／ストア・キュー）の容量と構造が肥大化するだろう。こうした機構はダイエリアと消費電力の両方に跳ね上がってくるので、それこそサブ5nm世代のプロセスとかではひょっとすると可能かもしれないが、7〜5nmプロセスをターゲットとする限りはこれ以上複雑化させるのは難しい。厄介なのは、自分のところの製品だけでつじつまが合えばよいインテルやAMDと異なり、ArmはあくまでIPベンダーだから、多くの顧客の意見のいわば最大公約数的なところを狙う必要があり、あまりバランスを崩した設計は受け入れられにくい。こうなってくると、IPC全体を引き上げるのはなかなか難しいことになる。

　そこでSolution-basedになるわけだ。システム全体の性能を引き上げるには時間がかかるが、取りあえず問題になっている箇所について、ピンポイント的に性能を引き上げるのはそれほど難しくない。そして、Armが現状問題視しているのが、AIの推論（Inference）における性能である。背景にあるのはこちら（図3）。こうしたアプリケーションが全てArmNNを使ってくれれば、Mali GPUなり機械学習（ML：Machine Learning）プロセッサなりにこうした作業がオフロードされるのだろうが、現状そうした動きは乏しい、というのがこのスライドの意味するところである。今後もCPU上でML推論のアプリケーションが動き続ける可能性は高く、これに対して何らかのアプローチが必要、というわけだ。

図3　多くのML推論のアプリケーションが、まだCPUのみで利用されているのが問題とされる（クリックで拡大）