ハードウェアアクセラレータプログラミングの未来

最新のスーパーコンピューターの多くは、ハードウェアアクセラレータに基づいています。 2013年11月のTOP500による2つの最速システムが含まれます。 アクセラレータは通常のPCでも配布されており、ポータブルデバイスにも表示されます。これは、アクセラレータプログラミングへの関心の高まりにさらに貢献しています。



加速器のこのような広範な使用は、高性能、エネルギー効率、低コストの結果です。 たとえば、Xeon E5-2687Wと2012年3月にリリースされたGTX 680を比較すると、GTX 680が4倍安く、単精度演算のパフォーマンスが8倍、メモリ帯域幅が4倍であることがわかります。ドル換算で30倍以上のパフォーマンス、ワットあたり6倍のパフォーマンス。 これらの比較結果に基づいて、加速器はどこでも常に使用する必要があります。 なぜこれが起こらないのですか？



主に2つの困難があります。 第一に、アクセラレータは特定のクラスのプログラム、特に十分な並行性、データの再利用、制御フローの連続性、メモリアクセス構造を持つプログラムのみを効率的に実行できます。 第二に、非常に大きな並列性、オープンなメモリ階層（ハードウェアキャッシュなし）、実行手順の厳格さ、メモリアクセス操作のマージなどのアーキテクチャの違いにより、通常のCPUよりもアクセラレータ用の効率的なプログラムを作成することは困難です。 したがって、これらの側面をさまざまな程度に隠し、アクセラレータプログラミングを容易にするために、いくつかのプログラミング言語と拡張機能が提案されました。



現在最も有名なタイプのアクセラレータであるGPUを使用して非グラフィカルアプリケーションを加速する最初の試みは面倒であり、制限された制御フローをサポートし、整数演算をサポートしないシェーダーコードの形式で計算を提示する必要がありました。 次第に、これらの制限は削除され、グラフィックチップでの計算の普及に貢献し、グラフィック以外の領域の専門家がそれらをプログラムできるようになりました。 この方向で最も重要なステップは、CUDAプログラミング言語のリリースで行われました。 C / C ++を拡張し、追加の修飾子とキーワード、関数のライブラリ、カーネルと呼ばれるコードの一部を起動するメカニズム、GPUを追加します。



CUDAが早期に採用され、独自の製品であり、高品質のCUDAコードを記述することが困難であるという事実と相まって、OpenCL、C ++ AMP、OpenACCなどのアクセラレータプログラミングへの他のアプローチが生まれました。 OpenCLはCUDAの非独占的な対応物であり、多くの大企業のサポートを受けています。 NVidiaチップだけに限らず、AMD GPU、マルチコアCPU、MIC（Intel Xeon Phi）、DSP、FPGAもサポートしているため、ポータブルです。 ただし、CUDAと同様に、非常に低いレベルです。 プログラマーがデータの移動を直接制御する必要があります。また、メモリー階層内の変数の保存場所を直接決定し、コードに手動で並列処理を実装する必要があります。 C ++ Accelerated Massive Parallelism（C ++ AMP）は中間レベルで機能します。 すでにC ++自体で並列アルゴリズムを記述でき、プログラマからすべての低レベルコードを隠します。 「for each」ステートメントは、並列コードをカプセル化します。 C ++ AMPはWindowsに関連付けられており、CPUをまだサポートしておらず、起動時のオーバーヘッドが大きいため、その助けを借りて短期コードを高速化するのは事実上不適切です。



OpenACCは、すでにアクセラレータープログラミングに対する非常に高度なアプローチであり、プログラマーがコードにディレクティブを提供できるため、コンパイラーにコードのどの部分を加速する必要があるか、たとえばGPUに出荷することによってコンパイラーに通知できます。 この考え方は、OpenMPを使用してCPUプログラムを並列化する方法に似ています。 実際、2つのアプローチを組み合わせる努力がなされています。 OpenACCは熟成段階にあり、現在少数のコンパイラーでのみサポートされています。



ハードウェアアクセラレータのプログラミング領域が将来どのように発展するかを理解するには、過去に他のハードウェアアクセラレータを使用して同様のプロセスがどのように進行したかを調べる価値があります。 たとえば、初期の高度なPCには追加のプロセッサがありました。これは、浮動小数点計算を実行するコプロセッサです。 その後、中央処理装置（CPU）を備えたチップに統合され、現在ではその一部となっています。 異なるレジスタと算術論理デバイス（ALU）のみがあります。 その後のSIMDプロセッサ拡張（MMX、SSE、AltiVec、AVX）は個別のチップとしてリリースされませんでしたが、現在ではプロセッサコアに完全に統合されています。 浮動小数点演算と同様に、SIMD命令は個別のALUで計算され、独自のレジスタを使用します。



驚くべきことに、これらの2種類の命令は、プログラマーの観点とは大きく異なります。 材料の種類とその操作は長い間標準化されており（IEEE 754）、今日どこでも使用されています。 これらは、通常の算術演算と組み込みの実データ型（高精度の実数の場合は32ビット、倍精度の場合は64ビット）を通じて、高レベルのプログラミング言語で使用できます。 それどころか、SIMD命令には標準がなく、その存在自体はプログラマにほとんど隠されています。 これらの命令を使用して計算をベクトル化することは、コンパイラに委任されます。 これらの命令を明示的に使用したい開発者は、特別な非クロスプラットフォームマクロを使用してコンパイラに連絡する必要があります。



GPUおよびMICアクセラレータのパフォーマンスはSIMDの性質によるものであるため、これらの開発は以前のSIMDアクセラレータを介して行われると考えています。 SIMDとそれを成功させたCUDAの主要な機能とのもう1つの類似点は、CUDAがGPUのSIMDエンティティの特性を隠し、プログラマーがベクトルを操作するワープ（ベクトル）ではなく、スカラーデータを操作するストリームの観点から考えることを可能にすることです。 したがって、間違いなく、アクセラレーターもプロセッサーを搭載したチップに転送されますが、プログラマーがハードウェアGPUデータ型に直接アクセスできないように、プログラムコードは通常のCPUコードに十分に埋め込まれないと考えています。



一部のアクセラレータは、AMD APU（Xbox Oneで使用）、統合されたHDグラフィックスを備えたIntelプロセッサ、NVIDIAのTegra SoCなど、従来のプロセッサとチップ上で既に結合されています。 ただし、アクセラレーターは、数学コプロセッサーおよびSIMD拡張で行われたのと同じ程度に従来のプロセッサーコアと組み合わせること、つまり、中央プロセッサーの一部としてレジスターセットおよび個別のALUにカットすることは難しいため、おそらく別個のコアのままになります。 。 最終的に、アクセラレーターは、切断されたキャッシュ、完全に異なるパイプライン実装、GDDR5メモリ、桁違いに多いレジスターやマルチスレッドなど、CPUとは異なるアーキテクチャーにより、非常に高速、並列、エネルギー効率に優れています。 その結果、アクセラレータでコードを実行する複雑さは依然として残っています。 通常、単一のチップ上に作成されたプロセッサコアでさえも、メモリ階層の下位レベルのみが共通しているため、CPUとアクセラレータ間のデータ交換の速度はおそらく向上しますが、依然としてボトルネックのままです。



デバイス間のデータ交換のプロセスを明示的に制御する必要性は、エラーの重大な原因であり、プログラマに大きな負担がかかります。 小さなアルゴリズムでは、計算そのものよりも多くのコードを記述してデータの交換を編成する必要があることがよくあります。 この負担をなくすことは、C ++ AMPやOpenACCなどの高レベルプログラミングアプローチの主な利点の1つです。 低レベルの実装でさえ、この問題を解決することを目的としています。 たとえば、よくデバッグされ統合されたメモリアクセスは、CUDA、OpenCL、およびNVIDIA GPUハードウェアソリューションの最新バージョンで行われた主な改善点の1つです。 それでも、優れたパフォーマンスを実現するには、OpenACCなどの非常に高レベルのソリューションであっても、通常はプログラマーの助けが必要です。 特に、必要な場所でのメモリの割り当てとデータの転送は、多くの場合手動で行う必要があります。



残念ながら、そのようなアプローチによって提供されるすべての単純化は、部分的な解決策にすぎないことが判明する場合があります。 将来のプロセッサが今日の（小型の）スーパーコンピューターに近いことを考えると、共有メモリで処理できるよりも多くのコアを搭載する可能性があります。 代わりに、各結晶には核のクラスターがあり、各クラスターには独自のメモリがあり、おそらくこれらの核の上に3次元空間で配置されると考えています。 クラスターは、MPIなどのプロトコルを使用して同じチップ上で実行されるネットワークによって相互に接続されます。 インテルは、ネットワーク機能が将来のXeonチップに追加されることを発表したばかりであり、これはその方向への一歩であるため、これは真実からそれほど遠くありません。 したがって、将来的には、レイテンシとスループットに最適化されたコアを組み合わせることにより、チップがますます不均質になる可能性があります。 ネットワークアダプター、圧縮およびエンコードセンター、FPGAなど



これは、そのようなデバイスをどのようにプログラムするかについて非常に重要な質問を提起します。 この質問に対する答えは、マルチコアCPU、SIMD拡張機能、および既存のハードウェアアクセラレータの今日の解決方法に驚くほど似ていると信じています。 これは、ライブラリ、自動化ツール、日曜大工と呼ばれる3つのレベルで発生します。 ライブラリ-誰かがすでにアクセラレータ用に最適化したライブラリからの関数への単純な呼び出しに基づいた最も単純なアプローチ。 多くの最新の数学ライブラリはこのクラスに属します。 ほとんどのプログラム計算がこれらのライブラリ関数で実行される場合、このアプローチの適用は完全に正当化されます。 これにより、複数の専門家が1つの優れたライブラリを作成して、このライブラリが使用される多くのアプリケーションを高速化できます。



C ++ AMPおよびOpenACCは、異なるアプローチ-自動化ツールを使用します。 このアプローチでは、ハードワークがコンパイラに転送されます。 その成功は、既存のソフトウェアツールの品質と複雑さに依存し、前述のように、多くの場合、プログラマーの介入が必要です。 それにもかかわらず、ほとんどのプログラマーは、ライブラリーから事前定義された関数を使用することに限定されないこのアプローチを使用して、すぐに良い結果を達成できます。 これは、複数の専門家グループがSQLの「内部」を実装する方法に似ており、通常の開発者は将来的に既製の最適化されたコードを使用できます。



最後に、日曜大工アプローチがCUDAおよびOpenCLで使用されます。 プログラマーは、ほぼすべてのアクセラレーターリソースへのアクセスを完全に制御できます。 実装が適切であれば、結果のコードは、前の2つのコードのいずれよりも優れています。 しかし、これはこのアプローチを研究するための相当な努力によって達成され、多くの追加コードを作成し、可能性のあるエラーの余地を増やします。 開発環境およびデバッグ環境に対するあらゆる種類の改善により、これらのすべての問題を軽減できますが、ある程度までしかできません。 したがって、このアプローチは主に専門家に役立ちます。 前の2つのアプローチで述べた方法を開発している人。



ライブラリの使いやすさにより、プログラマは可能な限りライブラリを使用できます。 ただし、これは、対応するライブラリ関数が存在する場合にのみ可能です。 人気のある地域では、そのようなライブラリが通常存在します。 たとえば、行列の操作（BLAS）。 しかし、関連分野や計算が構造化されていない場所では、アクセラレータライブラリを実装することは困難です。 適切なライブラリがない場合、もちろん十分に開発されていない限り、プログラマは自動化ツールを選択します。 ライブラリの形式では利用できず、パフォーマンスをそれほど要求せず、コンパイラによってサポートされる計算は、ほとんどの場合、自動化ツールを使用して実装されます。 それ以外の場合は、日曜大工メソッドが使用されます。 OpenCLはCUDAで提示された成功したソリューションを結合し、プロプライエタリではなく、さまざまなハードウェアソリューションをサポートしているため、MPIが分散メモリシステムのプログラミングの事実上の標準になったように、この分野で支配的になると考えています。



上記のハードウェア機能と進化プロセスを考慮すると、将来のプロセッサチップには独自のメモリを持つ多くのクラスタが含まれると言えます。 各クラスターは多くのコアで構成されますが、すべてのコアが機能的に同一というわけではありません。 各マルチスレッドコアは多数のコンピューティングユニット（つまり、機能ユニットまたはALU）で構成され、各コンピューティングユニットはSIMDコマンドを実行します。 将来のチップにこのすべてが一度に含まれない場合でも、それらはすべて1つの重要な類似性、つまり並列レベルの階層を持ちます。 このようなシステム用の効率的で移植性の高いプログラムを作成するために、大量並列処理手法と呼ばれるものを提案します。 これは、プログラマーがMPIプログラムを異なる数のコンピューティングノードに適応させる方法、またはOpenMPコードが異なる数のコアまたはスレッドに暗黙的に適応する方法の一般化です。



広範な並行性の基本的な考え方とこの名前の理由は、あらゆるレベルで、パラメーター化可能な広大な並行性機能を提供することです。 パラメータ化により、任意のレベルでプログラムの並列度が低下し、このレベルのハードウェア並列度と一致します。 たとえば、共有メモリを備えたシステムでは、最高レベルの並列処理は不要であり、1つの「クラスター」にインストールする必要があります。 同様に、計算ユニットがSIMD命令を実行できないカーネルでは、SIMDの幅を指定するパラメーターを1に設定する必要があります。 この手法を使用すると、マルチコアCPU、GPU、MIC、およびその他のデバイスの機能を実装できるだけでなく、将来のハードウェアアーキテクチャも実装できます。 この方法でプログラムを作成することは間違いなく困難ですが、広範な並行性により、単一のコードベースを使用して幅広いクラスのデバイスから高いパフォーマンスを引き出すことができます。



このアプローチは、n体の直接モデリングの問題でテストしました。 OpenCLを使用した広範な並列処理アルゴリズムの唯一の実装を作成し、NVIDIA GeForce Titan GPU、AMD Radeon 7970 GPU、Intel Xeon E5-2690 CPU、Intel Xeon Phi 5110P MICの4つの完全に異なるハードウェアアーキテクチャで測定しました。 すべての浮動小数点演算の54％がFMA演算（FMA-累積と乗算の演算）ではないことを考慮すると、広範な並列処理により、NVIDIA Titanの理論上のピークの75％、Radeonの95％、CPUの80.5％のパフォーマンスを達成できました。 MICの場合は80％。 これは単なる別の例ですが、その結果は非常に有望です。 実際、既存および将来のハードウェアアクセラレータシステム用のポータブルで高性能なプログラムを作成するための唯一のアプローチは、ある程度の同時実行性であると考えています。



[ ソース ]

2014年1月9日

カミル・ロッキーとマーティン・バーチャー