AMD，GPUとCPUで同じプログラムが動く「HSA」の最新動向を公表。Javaへの対応計画も明らかに

　米国時間2013年8月25日から27日まで，米国カリフォルニア州のスタンフォード大学にて，半導体やデバイス関連の学術イベント「Hot Chips」が開催されている。AMDはここで，同社が提唱するGPUコンピューティングフレームワーク「HSA」（Heterogeneous System Architecture）の取り組みと成果について発表するという。
　それに先立ち，報道関係者を対象とした電話会議で，その概要が説明されたので，今回はその概要をレポートしてみたい。

CPUとGPUを同じプログラムで扱えるようにするHSAは

OpenCLのよりよい実行環境を目指す

　HSAとはGPUコンピューティングを容易にするための仕組みであり，CPUやGPUといったハードウェアと，その上で動くドライバやランタイムといったソフトウェアで構成されている。AMDの次期主力APU「Kaveri」（カヴェリ，開発コードネーム）は，HSAに対応する最初のAPUになる予定だ。
　そもそもHSAとは何かという話は4月30日の記事でお伝えしているとおりだが，ここでも簡単に説明しておこう。従来のGPUコンピューティングでは，GPU用とCPU用にまったく別々のプログラムコードを書く必要があった。それに対してHSAでは，その面倒くささを取り除いて，同じプログラムでGPUとCPUを扱えるようにしようとしている点が重要だ。

　HSAを実現するためには，ハードウェアだけでなく，それらを使うためのプログラムを作るのに必要なソフトウェア面での整備が重要となるのだが，プロセッサメーカーそれぞれが好きに仕様を決めてハードウェアとソフトウェアを開発している現状だと，GPUコンピューティングを活用しようとするアプリケーション開発者は，異なるGPUやCPUごとにアプリケーションを作る必要がある。
　要するに，手間がかかりすぎるわけで，これがGPUコンピューティングの普及を阻害しているというのがAMDの見解だ。

HSA FoundationはAMDが中心になって，ARMやQualcomm，Samsungなどが創立メンバーとして設立された団体だ

　そこで同社が立ち上げたのが，HSAとそれに対応するソフトウェア環境やツール類の整備を共同で進めようとする業界団体「HSA Foundation」だ。HSA Foundationが整備した開発環境を使えば，ハードの違いはこれらソフトウェア群が吸収してくれるので，アプリケーション開発者は，GPUやCPU，それを搭載したシステム構成の違いをあまり意識することなくプログラムを作れるようになるというシナリオである。
　HSA Foundationの創設メンバーには，AMDを除くと，ARMやQualcomm，Samsung ElectronicsやTexas Instruments，さらに英Imagination TechnologiesにMediaTekといった，主にモバイル系のプロセッサ関連メーカーが名を連ねている。

　さて，「同じプログラムでGPUとCPUを扱える」と聞けば，「それってOpenCLがもうやってることじゃないの？」と思う人もいるだろうが，まさにそのとおり。HSAはOpenCLを置き換えようというものではなく，むしろOpenCLで作成したプログラムをより効率的に動かすための，ハードとソフトの枠組みを定義するものといえよう。

OpenCLとHSAの関係を示したスライド。HSAはOpenCLと置き換えるものではなく，むしろOpenCLのよりよい実行環境となるように設計されている

　HSA Foundationによれば，HSAは「OpenCLに最適化されたプラットフォームアーキテクチャ」であるという。詳しくは後述するが，OpenCLで作成されたプログラムを，HSAに対応する環境で動かすための変換が容易にできるよう設計されているし，OpenCLの仮想マシンである「LLVM」の開発にも，HSA Foundationのメンバーが参加していたりするそうだ。
　また，HSAの実現に必要な，GPUとCPUで同じメモリ空間を共有する仕組み――AMDアーキテクチャではhUMAと呼ばれる――は，OpenCLを動かすときにもメリットがあり，そのためOpenCL 2.0は，HSA Foundationと協力して定義した部分もあるという。
　いずれにしても，OpenCLがあってのHSAであり，矛盾したり対立するものではないという点は覚えておいてほしい。

　と，ここまでが前置き。今回説明があったのは，HSA Foundationが進めている開発環境やツールに関する現状と今後についてである。明確な「新しいトピック」はなかったのだが，4Gamerでは初出の話題も少なくないので，今回は現状の総まとめをしてみたいと思う。

HSA対応アプリをハードウェアに依存せずに動かす「HSAIL」

　というわけで，最初に紹介したいのが，「Bolt」と呼ばれるライブラリと「HSAIL」と呼ばれる中間コードである。

GPUによる並列計算に必要な基本機能を実装したBoltライブラリを使うことで，HSAを使ったプログラミングが容易になるという

HSAILはCPUやGPUから独立した中間コードで，GPUによる並列処理を実行する。また，OpenCLの下で動くことが可能なので，既存のOpenCLコンパライなどのツールがそのまま利用できるという

　まずBoltとは，HSA Foundationが開発した「GPUによる並列処理に必要な基本機能を組み込んだライブラリ」だ。アプリケーション開発者はBoltに組み込まれている機能を使うことで，並列処理に必要な機能を一から作らなくても済むようになる。

　もう1つのHSAILは，「HSAを使うアプリケーションやライブラリが，特定のCPUやGPUアーキテクチャに依存しないようにする中間コード（＝仮想的な機械語コード）」のことだ。
　まず，C/C＋＋などのプログラミング言語をHSAILに対応させて，これらの言語で開発したプログラムをHSAILで出力できるようにする。実際にそのプログラムを実行するときには，「HSA Finalizer」と呼ばれるプログラムを使って，各GPUやCPUから直接実行できる機械語コードに変換したり，JIT（Just In Time）コンパイラによって機械語コードに逐次変換しながら実行させたりする。こうすることで，GPUやCPUに依存しないHSA対応アプリケーションを実現できるというわけだ。

HSAシステムのブロック図。左側はOpenCLやDirectXを使う場合の「ドライバスタック」で，右側はHSA対応アプリのための「HSAソフトウェアスタック」。JITコンパイラや，次の段落で説明する「HSA Kernel Driver」（図中では「HSA Kernel Mode Driver」）も右側にある

　C/C＋＋コンパイラや関連ツールなどは，HSAILを出力できるように作ればいい。これらのツールにおけるコード生成や最適化のコードなどのアルゴリズムも，（理屈の上では）GPUやCPUのアーキテクチャに依存しなくなる。
　HSA Foundationの説明によれば，GPUやCPUなどといった具体的なハードウェアに依存するのは，最終的な機械語コードを生成するHSA Finalizerと，OSがGPUを管理するための「HSA Kernel Driver」だけとのこと。BoltやHSAILのコード生成部分，ランタイムライブラリなどは，GPUに依存しないように開発できるということだ。

HSAが提供するツール類のうち，HSA FinalizerとHSA Kernel Driverだけはハードウェアに依存。それ以外の部分，たとえばBoltやランタイムなどは，ハードウェアから独立している

JavaからGPU演算を利用可能に

　もう1つのトピックが，JavaをHSAに対応させる計画である。HSA Foundationによれば，いくつかの段階を経て，Javaに統合される予定という。

　第1段階では，OpenCLをJavaから使うためのライブラリとして，AMDが開発した「APARAPI」（A PARallel API）を，HSAILおよびHSA Finalizerに対応させる。APARAPIは，実行するハードウェアでGPU演算を利用できる場合，OpenCL側に「GPUによる処理」を依頼するが，ハードウェアがGPU演算に対応していないときはCPU側で実行するといった機能を備えている。
　この「CPU側で実行する」APARAPIの処理を，HSAILとHSA Finalizerを用いた処理に置き換える。これにより，Javaアプリケーション側を変更しなくても，HSAを使ったGPUコンピューティングが可能になるわけだ。

　さらに次の段階では，OpenCLが定義する中間コード「SPIR」（Standard Portable Intermediate Representation）をHSAILへと変換したうえで，HSA Finalizerでネイティブコード化させる。これにより，APARAPI自体には手を加えなくても，HSA対応ハードウェアを利用できるようにするとのことだ。

JavaのHSA対応プランを示した図。現在のAPARAPI対応が左端で，3つの段階を経て，最終的にJava VM（JVM）自体をHSA対応へと移行させる

　Javaは，2014年リリース予定の「Java SE 8」（Java platform Standard Edition 8）で，「Lambda」（ラムダ）と「Stream」という機能を取り入れる。これは，「Streamと呼ばれるデータ構造を新たに定義して，その処理をラムダ計算（ラムダ算法ともいう）で記述する」というものだ。
　大雑把に説明すると，データ構造とそれを処理するプログラムの書き方を新しく定義することで，配列に格納されたデータに対する“繰り返し処理”を開発者がいちいち明示的に記述しなくても，対象となるデータを処理できるようにする仕組みである。

JavaのHSA対応が最終段階まで進むと，Sumatra機能を実装したJVMの上で，LambdaおよびStream APIを使ったコードの一部をHSAILとして出力し，HSA Finalizer経由でGPUで実行可能なコードに変換されるようになる

　このLambdaとStreamという機能がJavaに組み込まれるのが，2014年のJava SE 8になるわけだが，HSA Foundationは2015年に登場予定の「Java SE 9」の世代で，このLambdaとStreamをHSA対応にする予定だ。これは，現在「Sumatra」という名称のプロジェクトとして開発が進められている。
　この方法のメリットは，Javaアプリケーション開発者がLambdaやStreamを使うようにアプリケーションを作るだけで，その処理にGPUを利用できるようになることだ。開発者はGPUの有無やアーキテクチャなどをまったく意識する必要がなくなるわけで，まさにGPUとCPUを区別せずに使えるようにするという，HSAらしい機能といえよう。

　さて，電話会議では，HSAの機能を利用したアプリケーションの具体例として，顔認識の処理や，「サフィックス配列でGPUと汎用CPUを利用した場合の比較結果」などが示された。
　前者はクライアント機器で利用されることが多い処理であり，後者は，クラウドサービスなどで，大量の文書データなどから高速に全文検索を行うときに利用されるものだ。まったく異なる2つの例を提示したのは，小規模なクライアントから大規模なクラウドサーバまでHSAは有効だと示す狙いがあると思われる。

　まず顔認識に関しては，CPUのみで処理した場合^※1と比べて2.5倍速く，消費電力は1フレームあたり60％も減少したというデータが示されている。GPUに処理させることで処理性能が上がるだけでなく，ハードウェア処理の比率が高まるため消費電力的にも有利というわけだ。
　同じ計測環境で実施したサフィックス配列のテストでは，CPUのみで処理する場合と比べて5.8倍の性能向上があり，消費電力は80％も減少したとのこと。この処理ではCPUとGPUが交互に処理をするので，同じメモリ空間を共有できるHSAの特徴が有効に作用するとのことだ。

※1 計測したシステムは，APUに「A10-4600M」を採用。メインメモリ容量は4GBとのことだ。

HSAにより顔認識アプリケーションを高速化した結果。CPUのみのシステムよりも2.5倍速く，消費電力は60％も減らせたという

大量のテキストデータに対する全文検索などに使われるサフィックス配列をHSAで処理した結果。性能は5.8倍に達し，消費電力は80％も減った

HSAを取り巻く状況と今後の予測

　それでは最後に，HSAを取り巻く状況について述べてみたい。なお，ここからの話は筆者の推測を交えたものになる。
　本稿の序盤で述べたとおり，HSA Foundationの創設メンバーは，モバイルプロセッサ系のメーカーが中心だ。「CUDA」で独自路線を行くNVIDIAが入っていないのは当然としても，IntelやMicrosoft，Google，Appleといったビッグネームがリストにない点は気になった人も多いのでなかろうか。

　その点だが，まず，JavaのHSA対応やOpenCLとの共存，あるいはサードパーティ製ライブラリのHSA対応といったことは，HSA Foundationだけでも進められるだろう。また，BoltはMicrosoftの「C＋＋ AMP」（※C＋＋からGPU機能を使うためのVisual C＋＋の拡張機能）に対応しているため，Windowsの標準開発環境であるVisual Studioを利用して，HSA対応アプリケーションを開発することは可能である。

　HSAに参加しているx86 CPUメーカーはAMDしかなく，ほかはARMアーキテクチャのプロセッサメーカーばかりである。そのため場合によっては，x86 CPUを使うPCよりも先に，スマートフォンやタブレットでHSAが普及するなんてことも，あり得る話だ。Javaへの対応が含まれるのも，Androidを多分に意識したものという気はする。
　AndroidのJava（Dalvik VM）はGoogle独自の実装で，OracleのJVMとは別物である。しかし，HSA Foundationの取り組みによってOracle側でJavaの仕様が変更されていくと，いずれはAndroidのJavaにも，HSA対応が導入される可能性はある。そもそもHSA Foundationに参加している創立メンバーは，Googleに対抗しているわけではないからだ。

　HSAがOpenCLとの共存を目指したのは，あるいはAppleとの関係が要因にあるのかもしれない。というのも，OpenCL自体がそもそもAppleの提唱した技術だからだ。現時点でiOSはOpenCLには対応していないが，MacOS Xには組み込まれている。将来的にiOSがOpenCLに対応する可能性は低くないと筆者は考えている。
　iOSがOpenCLに対応すれば，OpenCL経由でGPU演算を行うiOSアプリケーションが登場するのは当然の話だ。OpenCLで作られたアプリケーションを，HSA環境で動かすことは難しくない。iOSアプリケーションの開発者が，他のプラットフォームにOpenCL対応アプリケーションを容易に移植できるとなれば，GPUコンピューティングを普及させることに，大きな効果があるだろう。

　一方のMicrosoftだが，前述したとおり，x86アーキテクチャのWindows用に，HSA対応アプリケーションを開発することは可能である。また，Windows RTやWindows Phone 8は，すでにARMプロセッサに対応している。ARMアーキテクチャを採用するプロセッサメーカーの多くがHSAに対応すれば，将来的にはWindowsでも，なんらかの対応をせざるを得なくなると思われる。

　となると残るはIntelだが，こうして見るとHSA Foundationは，意外にもIntelの外堀を埋めつつあるように感じられる。こうした状況に対して，Intelがどういう回答を示すかは，2013年後半からしばらくの“見どころ”になるかもしれない。

HSA Foundation 公式Webサイト（英語）

Hot Chips 公式Webサイト（英語）