筆者は以前にJava環境でのミドルウェアや並列分散処理などのエンタープライズシステム関連の書籍を執筆しています。これらの書籍の技術は金融などでの低遅延・大量データ処理を目的としておりOpenCLの目的とは異なり、今後もそうしたアプリケーションでは使われるものと考えます。

しかし自動化や機械化が進むなかでビジネス要件も当然変化していくでしょう。業界通や有識者でなくとも、ソフトウェア業界が今までの手法では対応するのが難しい、新たな展開または変局に直面しつつあるということは感じられるのではないかと思います。

筆者の知る多くのJavaアプリケーションはJNI/JNAを通じて、C/C++でコードしたライブラリを活用して最適化がされています。OpenCLやCUDAを介してGPGPUを使う最適化は現在でも使用されていますが、利用範囲は限定されています。しかし遠くない将来にJavaでもOpenCLの実装が標準となる日が来る可能性は高いと思います。

Javaの利点は仮想マシーンがインストールされていれば実行環境を選ばず動作する「Run everywhere」という標語で表すことができます。大規模システムでJavaを使われる理由は各種フレームワーク、並列分散処理のツールが豊富にあることですが、GPGPUについては対応していません。

一方、OpenCLフレームワークはC言語で記述されていますが、「Run on all Microprocessors」という言葉で表されるように、CPUやGPUといったデバイスの種類に関係なくプログラムを実行できるのがOpenCLの導入要因です。

JavaとOpenCLを組み合わせるとパフォーマンスや実装のやりやすさから、複雑で高速なシステムを開発できるはずなのは誰でも発想はしますが、Javaが得意とする業務アプリケーションの主流派ではGPUデバイスが存在する下層の最適化に対して懐疑的です。これまでは高価なデバイスは数十台ないしは数百台購入して処理を分散するだけで何とか動いていたからです。しかし業務システムでデバイスに合わせてコードするなど絶対不要で不可能と断言ができる明確な論拠もまたありません。

例えば近い将来、HadoopやSparkで分散処理開発をしていたアーキテクトやソフトウェアエンジニアが、今とは比較にならない大容量のビッグデータを処理するタスクを割り振られることは十分に可能性が高いといえるでしょう。

具体例を勝手に想像してみると以下のような状況が考えられます。

こうしたミッションが当たり前のビジネス環境になったとき、ハードウェアの能力を引き出すプログラミングが有意なのは間違いないでしょう。