パラレルジャングルへようこそ! Part 4

この記事は、Dr.Dobb’s Go Parallel に掲載されている「Welcome to the Parallel Jungle!」の日本語参考訳です。

編集注記:
本記事は、2012 年 6 月 29 日に公開されたものを、加筆・修正したものです。
この一連の記事の著者である Herb Sutter 氏は、早い時期からプロセッサーのマルチコア化がソフトウェア開発に及ぼす影響と、ソフトウェア開発者が考えるべき移行における課題を示していました。Sutter 氏による「フリーランチは終わった」は、IT 業界での名語録にもなっています。この記事は、Sutter 氏が 2012 年の時点で「ムーアの法則」の終焉とそれを取り巻くソフトウェア開発の変化をまとめているものです。2020 年時点で読み返しても興味深い内容です。

このシリーズでは、モバイルデバイスからデスクトップ、クラスター、最高粒度のクラウドまで、並列化がもたらす影響について解説します。さまざまな並列化の実装が存在することによる混乱は、プログラミングにおける大きな挑戦をもたらしました。シリアル・プログラミングでフリーランチの恩恵を受ける時代はすでに終わりを迎えています。

変化が意味するもの: プログラマーの視点

メインストリームのハードウェア・パフォーマンスを活用するには、ソフトウェアの記述方法をどのように変えていけば良いでしょうか。基本的な結論は、私が『The Free Lunch Is Over (フリーランチは終わった)』で提案したものの反復および拡張となります。

アプリケーションを少なくとも大規模に並列化して、非ローカルコアやヘテロジニアス・コアを最大限に使用できるようにする必要がある。インボックスとインクラウドの両方で実現される長期的に継続される計算スループットの指数関数的成長を十分に活用する場合、この対応が必要になります。間もなく、メインストリームのアプリケーションで利用できる大部分の計算コアは非ローカルになるでしょう。
効率とパフォーマンスの最適化がより重要になる。より少ないハードウェア (制約のあるモバイル・フォーム・ファクターとムーアの法則の終了に伴いスケーリングが頭打ちになる中) でより多くの処理 (センサーベースの UI やより現実的な新しい体験) を行うことが要求されています。私は 2004 年 12 月に「すでに多くの最適化に役立っている言語は新しい活用分野を見つけるでしょう。これらの言語は競争力をつける必要はなく、より効率的に最適化できるようになるでしょう。パフォーマンス指向の言語とシステムの需要は長期にわたって増えることが期待できます。」という予測を書きましたが、この予測に変わりはありません。2011 年以降、C++ は主に表現の柔軟性とパフォーマンス効率の点から再度注目を集めています。効率が 2 倍のプログラムには 2 つの長所があります。
1. 特にムーアの法則がいかなる方法でもローカルのパフォーマンス向上を実現できなくなったとき、ローカル・ネットワークに接続されていないデバイスでプログラムを 2 倍の速さで実行できるでしょう。
2. プログラムが今後も拡大し続けても、Elastic な計算クラウドで常に半分の電力とコストでプログラムを実行できるでしょう。

プログラミング言語とシステムは、ヘテロジニアスな分散型並列処理に対処することが求められる。以前予測したように、メインストリームのソフトウェア開発に利用されている一部の言語 (特に C) がオブジェクトを無視することができても、マルチコアは無視できなかったことから、言語にとって基本的なホモジニアス・マルチコアは、かつてのオブジェクト指向プログラミングよりもはるかに大きな要因であったことが分かります。ホモジニアス・マルチコアの世界でさえ、基本的な並行性や並列性を無視したメインストリームの言語はありませんでした (批准されたばかりの C11 規格を含む)。今後は、標準ライブラリーを含む、メインストリームの言語と環境のすべてで、少なくとも分散型並列処理に加えてヘテロジニアスな並列処理も明示的にサポートすることが予想されます。メインストリームのアプリケーション開発で受け入れられ続けるには、これらのサポートは無視できないのです。

最後の項目について詳しく説明します。メインストリームのプログラミング・モデル (C、C++、Java、.NET) に追加すべき基本的な要素は何でしょうか。どのような形式にせよ、明示的にサポートする必要があると思われる項目を次に示します。

異なるパフォーマンスの計算コア (大きく高速、小さく低速) をサポートしてプロセッサー軸の下部のセクションに取り組む。
最低でも、メインストリームのオペレーティング・システムとランタイムは、一部のコアがほかのコアよりも速いことを把握して、アプリケーションのどの部分をどのコアで実行すれば良いか理解する必要があります。
完全にサポートしていないメインストリームの言語機能を含む異なる機能をコアで利用できるように、言語のサブセットをサポートしてプロセッサー軸の上部のセクションに取り組む。
次の 10 年間で、メインストリームのオペレーティング・システムは、(オペレーティング・システム自身で、あるいは Java/.NET VM や PPL をベースとする ConcRT ランタイムのような追加ランタイムを利用して) 異なる命令セットを使用して複数のコアを管理し、それらのコアの多くを利用して単一アプリケーションを実行できるようになるでしょう。プログラミング言語とツールは、メインストリームのプログラミング言語のサブセットのみを使用するように制限されたコードを開発者が記述できるように拡張されるでしょう (例えば、C++ AMP の restrict() 修飾子)。私は、ほとんどのメインストリームの言語では、このような単一の言語拡張は、オーバーロードとディスパッチについての既存の言語規則を利用することにより、開発者への影響を最小限に抑えることができると楽観視しています。
ローカルにスケーリングするだけでなく計算クラウドにもスケーリングする分散型アルゴリズムを提供して、計算のメモリー軸に取り組む。
OpenCL*、TBB、PPL のようなライブラリーとランタイムは、多数のローカルおよび非ローカル並列コア上で実行するループやほかのアルゴリズムを記述できるように拡張または複製されるでしょう。今は、1 セットのローカルの外付け GPU で 1,000 倍の並列処理を実行して正しいデータ領域を正しい計算カードに送り、結果を戻す parallel_for_each 呼び出しを記述できます。今後は、1 セットのクラウドベースの GPU で 10 億倍の並列処理を実行して正しいデータ領域を正しい計算カードに送り、結果を戻す同じ呼び出しを記述できるようになる必要があります。これは (例えば、単一マシンのメモリーに格納できる) ローカルデータを使用した分散型計算のほんの一例です。データサブセットはハブアンドスポーク方式で単純にコピーされます。
多くのノードにわたって分散される分散型データコンテナーを提供してデータのメモリー軸に取り組む。
次のステップは、データがすべてのノードのメモリーよりも大きい場合、分散型計算の正しいノードに正しいデータサブセットを (できれば自動的に) 移動させることです。
例えば、複数の冗長なクラウド格納領域にバックアップでき、同じ分散型の parallel_for_each 呼び出しのターゲットにできる distributed_array や distributed_table のようなコンテナーが必要です。一度に 100 ペタバイトのテーブルを効率的に更新できる parallel_for_each 呼び出しを使用してはならない理由はありません。Hadoop は、特定のワークロードと追加のワークロードでこの処理を可能にします。この処理は、メインストリームの言語のコンパイラーと標準ライブラリーでそのまま利用できる標準機能となるでしょう。
同じソースコードでグラフ全体を扱うことができるユニファイド・プログラミング・モデルを可能にする。
ハードウェアは 2 つの自由度を備えた 1 つのグラフにマップでき、その景観は統一されているため、将来、単一プログラミング・モデルでグラフ全体に対応できることが分かります。すべてのソリューションには少なくとも 2 つの基本的な特性があります。まず、言語へ全体的に統合する方法でプログラマーに言語サブセットを表現させることによりプロセッサー軸をカバーします。次に、データの位置を抽象化し、特定の計算のパフォーマンスを最適化するユーザー向けにコピーを管理する方法を提供しつつ、デフォルトでオンデマンドにデータサブセットをコピーしてメモリー軸をカバーまたは非表示にします。

しかし、最も困難な変化への対応は、クラウドをメインストリームのマシンの一部と見なす (すべてのローカルコアと非ローカルコアを、アプリケーションを実行するターゲットマシンの一部と等しく見なし、ネットワークはほかのコアへのバスと考える) ことでしょう。つまり、この数年で、100 万ウェイの並列処理が可能である (WiFi の範囲外の場合は 1,000 ウェイの並列処理が常に可能であることが保証される) と仮定してメインストリームのマシン向けのコードを記述するようになるでしょう。

今から 5 年以内に、デバイスが孤立しているときでも正しく動作し、WiFi の範囲内ではより高速に動作してより多くのコアに動的にアクセスするアプリケーションを開発することになるでしょう。オペレーティング・システム、ランタイム、ライブラリー、プログラミング言語、ツールのメーカーは、デバイスがネットワークに接続されていないときは 1,000 ウェイのローカルな並列処理を実行でき、デバイスが WiFi の範囲内にあるときはより多くのデータセットや追加の機能をより高速に実行し制御できる、計算を多用するアプリケーションを開発者が作成できるようにする必要があります。現在は (オンラインでのみ機能する) Shazam* のようなクラウドベースのアプリケーションにその前兆を見ることができますが、このフルバージョンが実現されるまでの道のりは長いものとなるでしょう。