メディア

Arm MLプロセッサ、明らかになったその中身モバイル機器でのエッジAI向け(2/5 ページ)

» 2018年10月10日 11時30分 公開
[大原雄介EE Times Japan]

MLプロセッサ、「4つの原則」

 これを実現するための4つの原則がこちら(図3)。

図3 Ingredientsは材料というか構成要素の意味だが、結果としてこの4つに集約されたというよりは、この4つの原則を打ち立て、それにあわせて実装した感がある 出典:Arm(クリックで拡大)

 まずStatic Schedulingであるが、そもそもArm MLプロセッサは推論側なので、ネットワーク構成は既に決まっており、これに合わせてArm NN Compilerから最適な形でCommand Streamが生成されることを前提に構成される(図4)。このCommand StreamはCompute Engineに対してStatic Schedulingの構成になる事を念頭に置いている(図5)。完全にStaticで、しかもキャッシュもないとなると、所要時間に不確定要素があるのは外部からデータをDMA経由でSRAMに取り込む部分だけで、以後の演算では(理論上は)処理時間を推定可能であり、最適化が行いやすいというわけだ。逆に言えば、きっちり最適化は必要になるだろう。

図4(左):ただArmNNを使う場合はともかく、AndroidのNNAPI経由で使う場合、その際にCompilerがArm以外の物でも対応できるのかは不明/図5:この説明を読む限りだと、下手をするとLoopというか条件分岐すらないかもしれない。もっとも後述されるProgrammable Layer Engineの方は普通にArm命令が動くようなので、このレベルのCommand Streamには無くても何とかなりそうな気もする 出典:Arm(クリックで拡大)

 次がEffective convolutions(図6)。

図6 逆にこれを全部オンメモリで保持するために、Compute Engine1つ当たり1MBという巨大なSRAMが搭載されることになっているのだろう 出典:Arm(クリックで拡大)

 Convolution、要するに畳み込み演算そのものであるが、CNNの場合には各層に対して入力特徴マップ(IFMs)と出力特徴マップ(OFMs)、それとフィルターに相当する重み(Weights)が演算に必要になるが、これを全てSRAMに常駐させることで、演算中に外部アクセスが必要ないように工夫されている。

 ただ1MBは(普通に考えれば)1層分のConvolutionには十分な大きさに見えるが、あまり考えずに流し込むと飽和というか溢れる可能性は当然ある。恐らく、そうしたことを保護するメカニズムはハードウェア側には保持しておらず、コンパイラ側で1MBを超過しないように制御しているものと思われる。ちなみに重みに関しては、MLプロセッサにロード前に静的に値が決まっているから、圧縮状態で保持しておき、展開エンジンで伸長するだけで済むが、入力/出力の特徴マップは動的に値が変わるから、これの圧縮/伸長までやると消費電力やエリアサイズ的に不利になる(あとスループットも落ちそう)と判断して、重みだけに留めたのだと思われる。

Copyright © ITmedia, Inc. All Rights Reserved.

RSSフィード

公式SNS

All material on this site Copyright © ITmedia, Inc. All Rights Reserved.
This site contains articles under license from AspenCore LLC.