Exoskeleton
ということで、Exoskeletonである。基本的な発想は、ApplicationからDeviceにもっと簡単にアクセスできるようにすることで、Latencyを減らしたいという発想である。具体的に言えば、Runtime経由でUser ApplicationがDeviceに直接アクセスすれば、余分なOverheadが最小限に抑えられる、という発想だ(Photo15)。ただ、だからといって既存のStandardを無視するわけにはいかないし、特定のベンダーに依存したインプリメントをすると応用が利かなくなる(Photo16)。
![]() |
Photo16:これが全て実現できれば勿論問題無いのだが、現実にはトレードオフが発生するのはご存知の通り。付け加えるならISVのサポート、もっと具体的に言えばMicrosoftがこれをサポートすることも、過去の歴史を見ると必須な気もするのだが。 |
さて、具体的な実装である。通常CPUとAcceleratorが混在する環境では、Accelerator用のロジックを別に組んでおき、これはこれで勝手にローダ等を使って流し込んで実行しておき、CPU上からI/Oポートなどを経由してパラメータを渡し、結果を受け取るといった手法が一般的だったのはご存知の通りである(Photo17)。これをPhoto18ではDomain Specific Programmingと呼んでいるが、このDomain Specific Programmingの代わりにIntelが新たに提案しているのが、一番右のDirect Programmingである(Photo19)。このDirect Programmingでは、Photo20の様なアクセスを実現することになる。要するにApplicationやLibrary/Runtimeから、直接Acceleratorを叩ける仕組みだ。
![]() |
![]() |
Photo17:これはこの手のプログラムを書いたことがある人ならおなじみの方法。クロスコンパイラを使ったマルチプラットフォームなども似た形になる。 |
Photo18:まぁこれは誇張している部分も多いから、全てが全てに当てはまる訳ではないが、一般論としてこうした問題がDomain Specific Programmingに存在するのは事実である。 |
まずMemoryの共有化だが、これはPCI ExpressのIOVに含まれるATS(Address Translation Services)を使うことで、AcceleratorがMapするMemory AddressとCPU(というか、そのApplicationが動くProcessのVirtual Memory Address)を重ねる形で実現する(Photo21)。