謎の多い「Armv9」について今分かっていることをまとめる：Arm最新動向報告（14）（3/3 ページ）

[大原雄介，MONOist]

「SVE2」は「SVE」＋「NEON」だが若干の書き換えが必要

　SVE（Scalable Vector Extension）2に関しては筆者の調査不足だったのだが、実は2019年3月に行われた「Linaro Connect Bangkok 2019」の中で、ArmはSVE2の概略を公開していた。そこで、その時の資料をベースにSVE2についてご紹介したい。

　まずSVE2の基本的なコンセプトだが、SVEをベースにしながら（つまり、レジスタ構成や、128ビットから2048ビットまで128ビット単位でレジスタ長を拡張可能な特徴などはSVEそのまま）、SIMD演算のために開発された「NEON」風の命令セットを追加した、というのがSVE2の基本的なコンセプトである（図6）。

図6　もっとも「NEON」は128ビット固定幅のSIMDなので、スケーラブル性をどう持たせるのかは難しいところだが（クリックで拡大）

　そもそもSVE自体はHPC向けに、それこそ算術演算をメインに実装した構成だったが、Arm自身「Neoverse V1/N2」ではNEONの代わりにSVEを実装することを明らかにしており（図7）、ところがそうなるとNEONで提供されていたもろもろの命令セットがないことが不足に感じられていたのだろう。

図7　「Neoverse V1/N2」ではNEONの代わりにSVEを実装することを明らかにしていた（クリックで拡大）

　SVE2で具体的に拡張されたのがこちら（図8）。青字がNEONから移植された命令、緑字が今回新規追加された命令である。（）内に書いてある内容は、その命令を利用する想定のアプリケーション例となる。ただし、SVE→SVE2は基本的に互換ではあるが、ID registerあたりは変更になるようで、ここだけ書き換えが必要になる。

図8　SVEの命令は基本的に継承しつつ、さらにここに挙げられた命令が追加された、ということだ（クリックで拡大）

　またNEONからSVE2でも若干の書き換えが発生する。NEONの場合SIMDレジスタのサイズが128ビットの固定長だったから、図9左側のようなデータ構成でも問題がなかった。ところがSVE2の場合、最大2048ビットまでレジスタ長が増えることになる。これを左詰めや右詰めで処理しようとした場合、「プログラムがレジスタ長を意識しなければならない」という、SVEの理念（レジスタ長に無関係にプログラムが記述できる）に反することになる。そこでSVE2では図9の右側のように、データの扱い方を変えることになったとしている。逆に言えば差は（今見えている限り）ここだけである。

図9　SVE2のレジスタも128ビット固定だったらNEONスタイルでも良かったのかもしれないが（クリックで拡大）

　ちなみにArmの説明によれば、NEONのDSP命令をSVE2に切り替えることで、1.2倍（128ビット）〜3.5倍（512ビット）に性能改善できるという（図10）。また、絶対性能で言ってもNEONに比べて最大で8倍近い性能改善が得られるとしている（図11）。

図10　NEONも128ビット幅だから、SVE2に書き換えるだけで20％の性能向上という計算になる（クリックで拡大）

図11　縦棒は右軸で、実行時間におけるSIMD命令の割合、折れ線は左軸でNEONを1.0とした場合の性能改善率となる。SIMD命令がマイナスというのは、利用していたNEON命令に相当するSVE2命令がなかった、という意味だろうか？（クリックで拡大）

　こちらもまだ命令セットの詳細などが明らかになっていない（SVE2のドキュメントはVLAのプログラミングガイドとサンプルコードを併せて近日発表という話だった）あたりは、Armv9のリリースタイミングがずれたことと無縁ではなさそうな気はするが、正式発表があった以上こちらも近日には詳細が出てくることを期待したい（現時点では、Armv9-Aの2021年3月版がこちらのWebサイトで公開されているだけである）。