OpenCLの数学ライブラリ?


35

科学コードでOpenCLを使用しようとした人からの情報を探しています。誰もが(最近)ViennaCLを試しましたか?もしそうなら、それはどのようにカスプと比較されますか?

何についてOCLTools?約束どおりですか?もしそうなら、それはOpenCLで数学カーネルを書き始めるための実行可能な方法でしょうか?


1
ViennaCLの開発者に短いメモを送って、これに関するサポートを依頼しました。
アロンアーマディア

1
この質問は、私の投稿scicomp.stackexchange.com/questions/366/future-of-openclの 1つにも関連しています。
アランP. Engsig-Karup

回答:


26

まず、このスレッドを紹介してくれたAron Ahmadiaに感謝します。

科学コードのOpenCLに関して:OpenCLは低レベルAPIであるため、合理的な生産性を達成するために何らかの方法でこの機能をラップすることが重要です。さらに、いくつかの計算カーネルが関係するとすぐに、OpenCLカーネルとメモリハンドルをアプリケーション内で頻繁に渡す必要がある場合、コードが非常にダーティになる可能性があります。私はOCLToolsを知らないので、この点でそれらが有用であるかどうかは言えません。

ViennaCLについては、私はViennaCLの責任者であるため、最近図書館で働きました。:-)以下では、わずかに大きなスコープでのcuspとの比較のリクエスト、つまりViennaCLとCUDAベースの数学ライブラリcuspおよびMAGMAを扱います。(少なくとも私たちの側では)進行中の開発がたくさんありますが、現在の状態のみが考慮されます。

機能性。MAGMAは、通常の機能インターフェイスを介して、高密度マトリックスのBLAS機能を提供します。この機能のほとんどは、演算子オーバーロードおよびその他の構文糖を使用してViennaCL 1.2.0でも提供されます。

同じ3つの反復ソルバー(CG、BiCGStab、GMRES)がcuspとViennaCLで提供されます。前提条件のセットは著しく異なります:Cuspは対角、SA-AMG、およびさまざまなBridson前提条件を提供します。ViennaCLは、不完全LU分解、対角前提条件、最近のさまざまなAMGフレーバー、およびスパース近似逆条件を提供します。私の知る限り、すべてのカスプ前提条件はすべてGPUで実行されますが、ViennaCLは特にセットアップ段階でCPUベースの計算に依存します。現在、COO、CSR、DIA、ELL、HYBのように、スパースマトリックス形式の数はより多くなっています。一方、ViennaCL 1.2.0はCOOとCSRを提供します。

ViennaCLには、MAGMAまたはカスプの一部ではない多くの追加機能があります。構造化マトリックスタイプ(循環型、ハンケルなど)、高速フーリエ変換、並べ替えアルゴリズム(Cuthill-McKeeなど)、線形代数のラッパー他のライブラリの型。

パフォーマンス。ViennaCLのより多くの機能とハードウェアサポートは、通常、CUDAベースの実装と比較するとパフォーマンスが低下するという代償を伴います。これは、CUDAがNVIDIA製品のアーキテクチャに合わせて調整されているという事実にも一部起因しますが、OpenCLは、ある意味で、異なるメニーコアアーキテクチャ間の合理的な妥協を表しています。

全体的に、ViennaCLは現在、特にBLASレベル3でMAGMAよりも低速です。理由は、ViennaCLの異なる焦点(密な線形代数ではなく疎)、したがってMAGMAの高度な最適化です。特に、MAGMAでは現在、BLASレベル3の操作がかなり高速です。

同様に、cuspを使用すると、全体的なパフォーマンスがわずかに向上します。ただし、スパース行列演算は通常、メモリ帯域幅に制限があるため、データのセットアップなどと比較して、差はかなり小さく、ほとんど無視できます。前提条件とそのパラメーターの選択は、通常、スパース行列ベクトル乗算のパフォーマンスの違いよりも全体的な実行時間に大きな影響を与えます。

移植性。ハードウェアの移植性に関しては、ViennaCLはOpenCLのおかげで、すべての主要ベンダーのCPUとGPUを使用できます。対照的に、cuspとMAGMAは適切なNVIDIA GPUに依存しています。

ViennaCLはヘッダーのみで、幅広いC ++コンパイラーでコンパイルでき、GPUサポートが必要な場合にのみOpenCLライブラリとリンクする必要があります。原則として、ViennaCLの汎用アルゴリズムはOpenCLリンケージなしでも使用できますが、cuspとMAGMAはコンパイルのためにNVIDIAコンパイラーを、実行のためにターゲットシステム上のCUDAライブラリーを必要とします。MAGMAにはBLASライブラリも必要です。BLASライブラリは、新しいシステムを見つけたりインストールしたりするのに少し面倒な場合があります。

API。MAGMAは、BLAS機能用のBLASスタイルの関数インターフェイスを提供します。cuspのC ++インターフェイスもBLASの一部の関数を使用しますが、演算子のオーバーロードはありません。ViennaCLのほとんどのインターフェイスは意図的にBoost.uBLASに似ており、演算子のオーバーロードなどの構文糖を特徴としているため、ViennaCLはBoost.uBLASのように使用することも意図しています。したがって、定義済みの操作とアルゴリズムのセットを呼び出すだけでなく、非標準のアルゴリズムを使用する場合でも、純粋にCPUベースの実行からGPUコードへの移行を可能な限り簡単にすることを目指しています。専用のOpenCLカーネルが必要な場合、独自のOpenCLカーネルをViennaCLに統合するためのフレームワークもあります。したがって、ViennaCLはGPUに新しいアルゴリズムを実装するのに必要な時間が最小限に抑えられるという意味での高い生産性。これらの節約は、cuspおよびMAGMAと比較して、パフォーマンスのペナルティ(ある場合)を大幅に上回る可能性があります。(単体テストスレッドでも、コード開発時間が科学の貴重なリソースであると述べられています。)

私の比較を通して、イデオロギーの問題(CUDA対OpenCL、BLASインターフェイス対演算子のオーバーロードなど)は確かに多くありますが、それらの議論は最初の質問の範囲を超えています。


3
こんにちはカール、SciCompへようこそ、情報をありがとう!
ジャックポールソン

1
MAGMAはレベル3のBLASを実行するだけでなく、最も一般的な分解(タイル、QR、コレスキーなど)のタイル化されたハイブリッドCPU / GPUアルゴリズム、および固有値の問題。MAGMAホームページ(icl.cs.utk.edu/magma)には詳細が記載されており、すべての機能がリストされた素敵なチラシがあります。
ペドロ

2

OpenCLは使用できますが、インフラストラクチャが不足しています。たとえば、GPUの後者の問題は大幅に改善されていますが、事実上の標準線形代数コンポーネントとある程度優れたプロファイリングツールを備えた重要な成熟標準数学ライブラリです。これは今日のCUDAで利用可能であり、このプログラミングモデルによるNvidiaの成功の一部に貢献できます。ただし、OpenCLは(ゆっくりと)追いついているようです。

今日、GPUプログラミングの出発点としてCUDAは問題ありません。必要な場合、OpenCLを代替手段として、たとえばコードの移植性を高めることを妨げるものはありません。基本的に、同じカーネルコードをCUDAとOpenCLの両方で使用できるため、CUDAからOpenCLに移行することは大きな問題にはなりません。これは、これをテストする独自の経験によって確認されています。パフォーマンスの観点からは、同じ最適化手法を使用することができ、些細な並行コードのコンパイラーは仕事をうまく行う必要があります(ループのアンロールなど)。


アラン、あなたがここでショーンの質問に答えているとは思わない...彼は、2つの比較ではなく、OpenCLライブラリの例を特に探している。
アロンアーマディア

5つの質問があります。私の答えは、最初の4つに対する一般的な回答であり、最後の4つに対するより直接的な回答です。
アランP. Engsig-Karup

この質問に答えるために努力をしてくれてありがとう!
アロンアーマディア
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.