問題なのは、Acceleratorもそうだが、Processorに関しては全部命令がバラバラであり、しかもプロセッサ間の同期を取るメカニズムがまちまちであることだ。
例えばGPU。Appleは2014年にOpenGLやOpenCLに代わるものとしてMetalを導入した。使い方はというと(語弊を覚悟でいえば)、よくあるAPIベースの呼び出しであって、プログラムから見ればデバイスのオブジェクトを作り、そのオブジェクトに対して操作を行うという形になる。これ、内部的にはおそらくPCI Expressのデバイスドライバの形を取ってGPUに対して基本的な操作を行う(GPUとCPUの間にCache Coherencyがあるかどうかは不明)形になっていると思われるのだが、これがオーバーヘッドを生んでいるのは疑う余地もない。Neural Processorもそうだし、ISPやVideo Processorなども当然同じであろう
ヘテロジニアス環境の理想で言えば、CPUとGPU、NPUその他が並列に並び、1つのメモリをCache CoherencyにUnified Accessできることが望ましいし、長期的には命令セットが共通化きれればより好ましい。加えて、とりあえず同期のメカニズムそのものを何とかしないといけない。現状の実装方法はいろいろだが、ポピュラーなのは、
という気の長い方式である。
実は外部デバイスを利用すると、大体が割り込みを使って同期を取る必要があり、この割り込みのハンドリングが非常に大きなオーバーヘッドであるために、煩雑に同期を取るようなケースではどんどん性能が落ちていくという欠点がある。ヘテロジニアス環境の最大のネックがここにある。
こうした課題への対応を、実はArmは既に始めている。MONOistに書いた記事、Arm「Custom Instruction」の衝撃、RISC-Vへの徹底抗戦を貫くのタイトルにも入っているCustom Instructionがそれだ。もちろん現状はCortex-Mベースの製品のみの対応だし、あくまでMCUのダイに収まる範囲のAccelerator/Coprocessorが対応であるが、理屈上はこれを拡張すればCortex-Aに適応することは難しくないし、専用ポートを用意して外部のGPUやNPUを同期させることも不可能ではない(Cortex-AのDynamIQには、このためのACPというポートもある)。RISC-Vは既にこれを実現しているし、MIPSやPowerPCでもこうしたCustom Instructionのサポートがあった。ただArmはCortex-Aグレードへの適用時期はまだ公開していない。
ではAppleは、ArmがこうしたCustom Instructionsに対応するのを待つのか? とりあえずは待たざるを得ない(というか、水面下でガンガンリクエストを出しているはず)だろうが、あまりそれが遅い or Appleの望むような仕様にならなかった場合に備えて「Plan B」を用意するというのは別に不思議ではない。
Copyright © ITmedia, Inc. All Rights Reserved.
Special
PR