見えてきたArm SVE2の概略、SVEとSVE2の違いはどこにあるのか？

Armは3月30日(日本時間)、最新アーキテクチャ「Armv9」についての説明会を開催し、SVEの発展形となる「SVE2」の存在を示した。

その際、「SVE2の方はまだ正体が明らかではない」とか書いたが、そのSVE2の概略が見えてきたので、ちょっとご紹介したい。

Armv9のアナウンスに合わせてArmは「Introduction to SVE2」を公開したが、そこからWhite Paperが入手できる。

ただ実は(筆者もまったく気が付いていなかったのだが)、Armは2019年4月にSVE2の概略を公開していたことが判明した。これはArmがLinano Connect Bangkok 2019の中で「New Technologies in the Arm Architecture」として紹介した中にSVE2の説明が入っていた、というものである。

そこで、この資料をベースにSVE2について考えていきたい。

SVE2は基本的にSVEの延長にあるが、元々のSVEがHPC向け(なので最初に実装されたのが富士通のA64FXとなった)なのに対し、SVE2はNEONと互換の命令を実装。NEONの後継命令という位置づけになった事が、ある意味最大の違いである(Photo01)。

Photo01:詳しくは後で説明するが、SVEよりも使いやすくなった

さてそのSVE2の主要な特徴がこちら(Photo02)。SVEはHPC向けに、ある意味綺麗さっぱりNEONとの互換性を捨てた構成だったが、SVE2はかなりNEONに寄せた構成になっている。

Photo02:()内がその命令の想定している用途である

またSVEと比べても、柔軟なデータアクセスが可能になっており、幅広い範囲のアプリケーションに利用可能、としている。一応SVEへの後方互換性は維持する様に配慮されているが、ID registerのみ変更が必要だそうで、逆に言えばそれだけ対応すれば済むということになる。ここで青地で記されたのが、従来NEONないしSVEで提供されてきた機能である。例えば「NEON-style DSP instruction」の場合、元々NEONの世代で、

FFTや行列演算などのブロックベース(一定のデータの塊単位)でのデータ処理
MPEG-4やH.264などをはじめとする動画/音声Codec
2D/3D Graphics
色空間変換
物理シミュレーション
CRCやリードソロモン、楕円曲線暗号など

といった作業に向いた命令が用意されていた。

こうした処理は本来DSPが得意とするところで、そうした命令をDSP風「命令」としていたわけだが、これをそのまま引き継いだ格好だ。もっとも命令そのものが互換なのか、同じ機能を持つ命令が用意される(命令そのものは非互換)なのかはまだはっきりしない。逆に言えば、例えばHeliumで搭載されたLow Overhead Branch Extensionの様な、DSP風「機構」が搭載されるかどうかは現時点では不明である。

「Cross-lane match detect/count」以降の特徴は、主にSVEからの継承である。

新しいのがBit shuffleや暗号化関連命令である。まだ命令セット一覧が公開されていない(現状はSVEどまりである)ので断言はできないが、x86のSSE/AVXにかなり近い構成になった格好だ。

ちなみにNEONからの乗り換えにちょっとした障害もある。演算の結果を異なるサイズにする場合の対応だ(Photo03)。

Photo03:なのでNEONでこうした使い方をしている場合は、ちょっと書き換えが面倒になるのは致し方ない

NEONは128bit幅で固定なのに対し、SVE/SVE2では最小単位が128bitで、最大2048bit幅までスケーラブルに拡張できる。これを考えた場合、NEONの方式は(不可能ではないが)相当頭を捻る必要がある。特に面倒なのがスケーラブルという部分で、SVEレジスタのサイズにあわせて「どこにデータを入れるか」をきちんとプログラムでハンドリングする必要が出てくる。これに比べるとSVEの方式はスケーラブルに展開しやすい。

ところで気になる性能であるが、NEONと128/256/512bit SVEの性能比較がこちら(Photo04)。

Photo04:棒グラフ(左軸)がベクタ化率、折れ線(右軸)が性能比

これは以前、安藤先生の記事にも出てきたスライドで、性能改善率は当然アプリケーションによって性能は変わってくるが、あまり改善しないNAS Parallel Benchmarkで2倍、ASC Coral HACCで8倍とずいぶん差が大きい。

ではSVE2は？　というと、HPC向けに関してはSVEと同様(別にSVE2になって性能がさらに上がったりはしない)だが、DSP/マルチメディア系性能は128bit幅で1.2倍、256bitで2倍、512bit幅で3.5倍に達するとする(Photo05)。

Photo05:同じ幅(128bit)でも1.2倍程度には高速化されるが、本質はやはり幅を広げてその分高速化するのが簡単、というところだろう

Photo06がもう少し広範なアプリケーション全体での比較である。

Photo06:先のPhoto05と同じく、縦棒はベクトル化率、折れ線が性能改善比となる。比較はNEON×2 vs 128bit SVE2×2 vs 256bit SVE2×2

Vector化がうまくいかないもの(eembc_automotive_idctrn01とか)はVNEONと性能が大差ないが、うまくVector化出来るそれだけ性能が大きく改善するという訳で、今後はArmでも(昨今のx86と同様に)「如何にSVE2を利用できる様にするか」が性能改善のポイントになってくるようだ。

ところでここからは余談なのだが、Linano Connect Bangkok 2019で紹介された「New Technologies in the Arm Architecture」はSVE2だけではなく、Transaction Memoryも含まれていた(Photo07)ので、ちょっとこれを紹介しておきたい。

Photo07:Arm自身はまだマルチスレッドはごく一部のCPU IPでしかサポートしていないが、Marvell(旧Broadcom)のThunder X2の様に4way SMTをサポートするCPUもあるので、こうしたプロセッサの同期にTransaction Memoryが役に立つと考えたようだ

そもそもTransaction Memory、以前から研究は広くされていたが、量産品への実装はIBMによるPOWER8が最初。次いでIntelがHaswell世代でTSX(Transaction Synchronization Extensions)としてサポートしたが、例えばAMDは現時点でもTransaction Memoryはサポートしていないという具合に、必ずしも広く利用されている機能ではない。

Armにしても現時点ではこれをサポートするという表明はなされていないが、そもそも説明がある時点で将来のArmプロセッサではこれをサポートする予定がある、という話になる(Photo07)。

Transaction Memoryそのものの原理は以前、安藤先生が解説しておられるのでこちらをご覧いただくとして、ArmはTransaction MemoryについてTME(Transaction Memory Extension)という命令拡張を用意することを明らかにした(Photo09)。

TMEを実行する場合、当然2つ以上のスレッドが当該メモリ領域をアクセスしようとすることが前提なので、場合によってはTransactionが成立しない(Rollbackする)場合がある。これはStatus Registerにそれぞれの状態を書き込んで返すという形で実装される(Photo09)。

Photo08:もちろん、こんな簡単な話では済まない

Photo09:これは要するにtstartの戻り値という事になるのだと思う

ところで一般にTransaction MemoryではHLE(Hardware Lock Elision)とRTM(Restricted Transacitonal Memory)という2種類の方式があり、Intelの場合だと両方をサポートするのだが、ArmはHLEのみのサポートとした模様だ(Photo10)。

Photo10:何でRTMをサポートしないのか、の説明は残念ながらない

このHLEとRTMの違いは、これも安藤先生の解説に詳しいのでこちらをお読みいただくとして、使い方の例(Photo11)を見ると、限りなくIntelのTSXに近い。

Photo11:正確に言えばTSXでHLEを使う場合に近い。まぁ概念も実装も似ていれば、当然サンプルコードも良く似たものにならざるを得ない

現時点でArmはTMEをどの世代のArmコアでサポートするか明らかにしていないが、すでにLLVMやGNU Tools/Glibcなどでのサポートが終わっている「はず」というあたり、そう遠くない世代な気がする。もちろん、スマートフォンでTMEを入れてもあまり意味が無いので、対象はNeoverse向けという気はするが、案外遠くない時期にサポートが入っても不思議ではない。［こちら](https://news.mynavi.jp/photo/article/20210331-1862066/images/004l.jpg)を見る限り、Armv9.2-Aまではなさそうだから、Armv9.3-A以降だろうか。機会があったらもう少し細かくIan Smythe氏に問い詰めてみたいところである。