Apple Siliconがやってくる

最終回：Apple Siliconがやってきた　そのさらに先、「Apple ISA」への遠い道のり（2/3 ページ）

公開 2020年11月25日 07時22分

更新 2020年11月25日 14時46分

著者

大原雄介

[ITmedia]

印刷する連載新着通知を受け取る Googleで優先するソースとして追加

ヘテロジニアス環境の課題

　問題なのは、Acceleratorもそうだが、Processorに関しては全部命令がバラバラであり、しかもプロセッサ間の同期を取るメカニズムがまちまちであることだ。

　例えばGPU。Appleは2014年にOpenGLやOpenCLに代わるものとしてMetalを導入した。使い方はというと（語弊を覚悟でいえば）、よくあるAPIベースの呼び出しであって、プログラムから見ればデバイスのオブジェクトを作り、そのオブジェクトに対して操作を行うという形になる。これ、内部的にはおそらくPCI Expressのデバイスドライバの形を取ってGPUに対して基本的な操作を行う（GPUとCPUの間にCache Coherencyがあるかどうかは不明）形になっていると思われるのだが、これがオーバーヘッドを生んでいるのは疑う余地もない。Neural Processorもそうだし、ISPやVideo Processorなども当然同じであろう

AppleのMetal

　ヘテロジニアス環境の理想で言えば、CPUとGPU、NPUその他が並列に並び、1つのメモリをCache CoherencyにUnified Accessできることが望ましいし、長期的には命令セットが共通化きれればより好ましい。加えて、とりあえず同期のメカニズムそのものを何とかしないといけない。現状の実装方法はいろいろだが、ポピュラーなのは、

GPUやNPUが処理が終わったら、CPUに対して割り込みを掛ける
割り込みを受け取ったCPUは現在の処理を一端棚上げにして、割り込み処理ルーティン（ISR：Interrupt Service Routine）を起動する
ISR内部では割り込みの内容を判断し、関係するThreadに対して通知を行う処理を行い（この時点ではまだ処理を積んだだけで通知そのものは行われない）、ISRを抜ける。
CPUは先ほど棚上げにした処理を再開する。
そのうちに関係するThreadが実行可能になると、先にISRで積んだ「通知を行う処理」が実行され、そのThreadにGPUやNPUが処理を完了したことが通知される。

という気の長い方式である。

　実は外部デバイスを利用すると、大体が割り込みを使って同期を取る必要があり、この割り込みのハンドリングが非常に大きなオーバーヘッドであるために、煩雑に同期を取るようなケースではどんどん性能が落ちていくという欠点がある。ヘテロジニアス環境の最大のネックがここにある。

　こうした課題への対応を、実は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グレードへの適用時期はまだ公開していない。

Arm Custom Instructionの流れ

　ではAppleは、ArmがこうしたCustom Instructionsに対応するのを待つのか？　とりあえずは待たざるを得ない（というか、水面下でガンガンリクエストを出しているはず）だろうが、あまりそれが遅い or Appleの望むような仕様にならなかった場合に備えて「Plan B」を用意するというのは別に不思議ではない。

次ページへ Appleの「Plan B」、Apple ISAとRosetta 3