取引におけるOpenCL - ページ 10

[MetaQuotes]

簡単、効果的、効率的: PyOpenCL と PyCUDA を使用した GPU プログラミング (1)

PyOpenCL と PyCUDA を使用した GPU プログラミング (1)

このビデオでは、Python を使用した効率的な GPU プログラミングのためのパッケージである PyOpenCL と PyCUDA を紹介します。講演者は、Nvidia の CUDA とは異なり、他のベンダーのデバイスと柔軟に通信できる OpenCL の利点を強調しました。プログラミング モデルには、グリッド内の異なる正方形を区別するための情報のインデックス付けが含まれており、並列処理が向上し、メモリ キャッシュへの依存度が低くなります。さらに、PyOpenCL と PyCUDA を使用すると、コンピューティング デバイスとの通信やプログラミングが容易になるため、生産性が向上し、非同期コンピューティングが容易になります。講演者は、デバイス メモリの管理の重要性と、PyOpenCL および PyCUDA でのアトミック操作の可用性についても説明します。

• 00:00:00 このセクションでは、Andreas Faulkner が、Python を使用した簡単、効果的、効率的な GPU プログラミングのためのパッケージとして PyOpenCL と PyCUDA を紹介します。 Faulkner 氏は、PyOpenCL と PyCUDA により、Python インターフェイスを介した CUDA または OpenCL を介した GPU のプログラミングが可能になると説明しています。さらに、Nvidia の CUDA デバイスと比較して、他のベンダーのデバイスと通信できる柔軟性による OpenCL の利点を強調しました。 Faulkner 氏は、GPU を使用すると、多数の粗く単純なコンポーネントによって命令が制御される別のシステムを実装することで、従来の CPU よりも優れたパフォーマンスを実現できると主張しています。最終的に、PyOpenCL と PyCUDA を使用すると、プログラマは 16 の独立した命令を制御して科学計算ワークロードを実行できます。
  
  
• 00:05:00 このセクションでは、講演者が Cindy Acosta の核となるアイデアについて説明します。これには、メモリの遅さの問題を解決するために並列処理を追加することが含まれます。 ALU を追加し、共有ストレージとコンテキスト ストレージの量を増やすことにより、チップはメモリ ストールによってブロックされた場合でも有用な作業を継続できます。目標は、無限の数のコアをプログラムすることです。プログラム内で並列処理を表現することは、並列プログラムを逐次プログラムに変換するよりもはるかに簡単です。究極のハードウェア設計には、並列性を高め、メモリ キャッシュやアウトオブオーダー実行への依存度を下げる方法で編成された 128 個の独立した命令セットが含まれています。
  
  
• 00:10:00 このセクションでは、ハードウェアの真のスケール特性を維持することを目的として、無限に多くの森と障害が存在する画像にコンピューターのハードウェアをマッピングする方法を講演者が説明します。これは、作業項目の数をグループ化する 2 次元グリッドを使用して作業項目を定義することによって実現されます。これらのグループをマシンにマッピングすることで、追加の並列処理を順次実行に変えることができます。 PyOpenCL と PyCUDA によって提供されるプログラミング モデルは、チップがドロップする並列処理のプールのように動作し、チップ上に並列処理が残っていない場合にのみ順次実行に移行します。
  
  
• 00:15:00 ビデオのこのセクションでは、講演者が PyOpenCL と PyCUDA を使用した GPU プログラミングのプログラミング モデルを説明します。このモデルには、単一の関数を複数回実行することが含まれており、各実行はグリッド内の正方形に対応します。グリッド内の異なる正方形を区別するには、ローカル ID やグローバル ID などのインデックス情報が使用され、この情報を使用してデータにアクセスする関数が作成されます。講演者は続けて、OpenCL は GPU プログラミングに使用されるオープン コンピューティング言語であり、ランタイム コード生成を提供し、ボックス内で利用可能なさまざまなコンピューティング能力と対話する柔軟な方法であると説明しました。
  
  
• 00:20:00 このセクションでは、講演者が OpenCL の使用法と実装について説明し、OpenCL には少なくとも 3 つの高品質な実装があると述べています。 CUDA は以前から存在しており、NVIDIA の Web ページに存在するためより目立つようになりましたが、OpenCL は Apple を含むいくつかの組織で採用されています。講演者は、OpenCL でクラスを教えたところ、数人の学生が CUDA の代わりに OpenCL を使用することを選択し、それが良いアイデアであると感じたと述べています。さらに、講演者は、OpenCL と CUDA の間に概念的な違いはあまりなく、パフォーマンスの違いは多くの場合人為的なものであることを強調しました。
  
  
• 00:25:00 このセクションでは、講演者が GPU プログラミングのアーキテクチャについて説明し、ホストとランタイム インターフェイスから始めて、さまざまなプラットフォームとその中のコンピューティング ユニットについて説明します。次に講演者は、PyOpenCL と、Python がさまざまなコンピューティング デバイスと通信してプログラムできるようにする PyOpenCL の機能を紹介します。これにより、生産性が向上し、スピン処理などが可能になります。 PyOpenCL の使用は、技術的な詳細を気にすることなく、Python などの高級言語からコンピューティング デバイスを利用するのに適していると考えられています。
  
  
• 00:30:00 このセクションでは、講演者は、コンパイル時と実行時のコンパイルの違いと、GPU のスクリプト作成がどのように防御可能な行為であるかについて説明します。同氏は、速度がそれほど重要ではない高レベルのスロースモークのような特定のコードの場合、GPU プログラミングにスクリプト言語を使用することが合理的であると説明しています。さらに、CPU は GPU プログラミングにおいて多かれ少なかれ単なる交通警官に制限されているため、Python のようなスクリプト言語を使用すると、作業を非常に高速に実行できます。次に講演者は、PyOpenCL と、コンパイルのネイティブ サポートを使用してユーザーが実行時に C ソース コードを実行できるようにする方法を紹介します。
  
  
• 00:35:00 このセクションでは、発表者が PyOpenCL と PyCUDA を使用した GPU プログラミングをデモンストレーションします。まず、乱数の配列から開始し、GPU にデータを転送するためのバッファを作成する OpenCL コンテキストを作成します。次に、データを乗算する CL プログラムを作成し、サイズ 8 のグリッド上でコマンドを使用してそれを呼び出します。発表者はプログラムの単純さを強調し、CUDA とは異なり、より大きなグリッド サイズでもプログラムが問題なく実行されることを実証しました。彼らは、望ましい出力が得られたことを確認して結論を出し、プログラミング モデルを理解するのに役立つようにプログラムにさらに変更を加えることを提案しています。
  
  
• 00:40:00 このセクションでは、講演者が PyOpenCL および PyCUDA プログラミングにおけるグリッド サイズとワークグループ サイズの概念を説明します。グローバル グリッド サイズは、ワークグループのサイズに関係なく同じままであることに注意することが重要です。ワークグループのサイズを変更すると、パフォーマンスに大きな違いが生じる可能性があります。講演者は、16 x 16 のワークアウトのグループを使用するようにプログラムを変更する方法、およびカテゴリに 256 のワークアイテムを使用するのではなく、グループごとに 1 つのワークアイテムを使用してベンチマークを行う方法についても説明します。 CPU と GPU は相互に通信しており、実際の計算は非同期で実行されることに留意することが重要です。
  
  
• 00:45:00 このセクションでは、インストラクターが PyOpenCL のカーネル ログとドット待機コマンドを使用してタイミングを測定する方法を説明します。ベンチマークを実行するとき、時間測定値はカーネル ログの前後に記録され、カーネルの完全な実行を保証するために最後に dot wait コマンドが使用されます。講師はまた、PyOpenCL と PyCUDA が基礎となるレイヤーへの完全なアクセスを提供し、リソースを自動的に管理することで、生産性の向上が容易になる方法についても強調しました。さらに、これらのライブラリは他のフレームワークとシームレスに統合され、Nvidia などのベンダーの拡張機能を含むすべての主要なオペレーティング システムで動作します。
  
  
• 00:50:00 このセクションでは、講演者は PyOpenCL と PyCUDA でのアトミック操作の利用可能性について説明し、これらは標準の基本部分の一部として提供されており、ハードウェアで利用できない場合はエミュレートされないと述べています。講演者はコード生成における文字列表現の使用についても言及しており、これは PyOpenCL の上に構築されるものであると述べています。このセクションは、スピーカーがデバイス メモリを慎重に管理することの重要性を強調し、PyOpenCL と PyCUDA に関するドキュメントが入手可能であることに言及して終了します。
  
  
• 00:55:00 このセクションでは、PyOpenCL と PyCUDA がどのようにしてプログラマーの生産性を高め、オープン ソース ライブラリを使用すると簡単なタスクをコード化するときに貴重な時間を節約できるかを講演者が説明します。また、Python に対する誇大広告を生成し、C++ を知らないプログラマーがプログラムを迅速に作成できるようにすることもできます。オープン CL で複数のコンテキストを使用すると、単一ソースからのプログラムの大規模な計算を調整するのに役立ちます。

[MetaQuotes]

簡単、効果的、効率的: PyOpenCL と PyCUDA を使用した GPU プログラミング (2)

PyOpenCL と PyCUDA を使用した GPU プログラミング (2)

このビデオでは、PyOpenCL と PyCUDA を使用した GPU プログラミングのさまざまな側面について説明します。講演者は、プログラムのコンテキストを理解することの重要性を説明し、ランタイムとデバイス管理の主要なコンポーネントに焦点を当てます。これらは、PyOpenCL と PyCUDA のコマンド キュー、同期、プロファイリング、バッファーに関する貴重な洞察を提供します。このビデオでは、ソース コードからプログラムを構築してコンテキスト内でコードを実行する方法についても触れており、デバイスで要素ごとの操作と同期機能を使用することの重要性を強調しています。講演者は最後にステージング領域の利点について説明し、フックとして公開されている他のデバイス固有の操作を検討するよう出席者に勧めます。

• 00:00:00 このセクションでは、講演者が PyOpenCL および PyCUDA プログラミング フレームワークの概要を提供し、ランタイムとデバイス管理の概念とコンポーネントについて説明します。講演者は、プログラムのコンテキストと、OpenCL ランタイムを使用してさまざまなデバイスと通信する方法を理解することの重要性を強調しました。講演者は OpenCL の実装の詳細にも触れ、特に Apple の実装に焦点を当てています。講演者は「おもちゃ屋」のツアーで締めくくり、PyOpenCL と PyCUDA を構成するさまざまなコンポーネントの概要を説明します。
  
  
• 00:05:00 このセクションでは、講演者は、PyOpenCL と PyCUDA が ICD ローダーを使用して、動的ロードを通じてディレクトリ内の共有ライブラリの実際の実装を検索することに注意しました。プラットフォームは、独自のコンテキストを持つデバイスのグループを提供し、デバイスを選択すると、ユーザーはそれを目的のデバイスに割り当てることでコンテキストを作成できます。コンテキストは複数のデバイスにまたがることができ、プログラムやコマンドの作成に使用できます。コマンドの目的は、ホストとデバイスの間を仲介し、非同期で実行することです。講演者は、作業はキューに送信され、デフォルトでは順次に実行されること、および 1 つのデバイス上で複数のキューをアクティブにできるため、並列処理が可能であることを説明しました。
  
  
• 00:10:00 このセクションでは、スピーカーが PyOpenCL と PyCUDA を使用して GPU プログラミングをセットアップする方法を説明します。彼は、デバイス固有であり、プロファイリングを含む複数のプロパティを持つことができるコマンド キューの作成について説明します。次に、Intel プロセッサを使用したベクトル加算を実演し、操作の時間範囲を監視するためのイベント識別子の重要性を説明します。全体として、講演者は GPU プログラミングにおけるコマンド キューの有用性を強調しています。
  
  
• 00:15:00 このセクションでは、講演者が PyOpenCL と PyCUDA を使用した並列コンピューティングにおけるホストとイベント間の同期の重要性について説明します。彼らは、複数のイベントを同時に待機する方法と、キュー間の安全な切り替えを確保するためにコマンド キューのメンバーを互いに待機させる方法について説明します。講演者は、データの依存関係と、データが相互にどのように依存しているかをデバイスに通知するために実装でどのように表現できるかについても説明します。さらに、プロファイリングを使用すると、タイミングを細かく設定したり、イベントが発生したときの正確な記録が可能になり、非常に詳細なパフォーマンス データが得られます。
  
  
• 00:20:00 このセクションでは、GPU プログラミングにおけるプロファイリングの仕組みと、実行にかかる時間を見積もる方法について講演者が説明します。コード内でのマーカーの使用とタイミング データの取得方法についても説明します。講演者は、有向非巡回グラフと、異なる GPU 上の複数の実行ストリーム間で通信する際の有向非巡回グラフの使用方法、およびメモリを扱う際の同期と依存関係管理の重要性を紹介します。全体として、講演者は PyOpenCL と PyCUDA を使用した GPU プログラミングのさまざまな側面について貴重な洞察を提供します。
  
  
• 00:25:00 このセクションでは、講演者は PyOpenCL と PyCUDA のバッファについて説明します。これは、別のデバイス上にあるカーネルに送信できる、型情報を持たないメモリの塊です。バッファ抽象化により、データの保存場所から完全に分離され、同じデバイス内で発生する場合でもすべての効率が確保されます。講演者は、コピー、ホスト ポインターの使用、および割り当てという 3 つの異なるタイプのメモリ割り当てについても詳しく説明します。実装には、最も効率的にデータを送信するためにどのデバイスを経由する必要があるかを知る必要があるすべての情報が含まれています。ただし、その代償として、あるデバイスから別のデバイスにデータを転送するのに費用がかかる可能性があります。
  
  
• 00:30:00 このセクションでは、講演者は、バッファをコンテンツに関連付けてそこにデータを転送することで、データを転送する「ポスト」テクニックを回避する方法を説明します。ただし、バッファの物理的な場所が存在しない場合、その結果、1 つのカーネルの寿命を超えて存続するベースへのポインタを保持できなくなると彼らは指摘しています。講演者はまた、クラスターでは、クラスター全体のすべての OpenGL デバイスの単一ビューを 1 台のマシンに送信するコンテキストを作成する選択肢があり、これにより最前列全体にわたって最も厳格なボキャブラリーを活用できることにも言及しました。メモリの場所を取得するために、ユーザーはバッファを連絡先に接続しますが、実装はメモリがどのデバイスのアクティブコードであるかを知りません。
  
  
• 00:35:00 このセクションでは、スピーカーは、PyOpenCL と PyCUDA でベクトルとバッファーを指すインデックスを使用する方法を説明します。バッファはメモリとホストを使用して指定でき、特定の要件を満たす方法でインスタンス化できます。これを行う 1 つの方法は、トランスクリプトをロックしてメモリ空間を使用できるようにすることです。講演者は、通常はデフォルトで転送をブロックするのが賢明だとアドバイスします。これにより、データが再利用される前にメモリ転送が確実に行われるようになります。
  
  
• 00:40:00 このセクションでは、スピーカーはソース コードからプログラムを構築することによって、コンテキスト内でコードを実行する方法について説明します。講演者は、ユーザーが特定の構築物にカーネルを組み込んで引数内で作業したり、他のものを振動させたりできると述べました。引数には、null ポインター、numpy サイズのスカラー、またはバッファー インターフェイスを持つものを指定できます。ただし、これらの引数を適切に数えることが重要です。講演者は、確認されたスカラーのデータ型について OpenCL に事前に通知し、それらを忘れないようにすることで、毎回明示的に整数のサイズを指定することを回避する方法があることを共有しました。さらに、講演者はデバイス マネージャーについても言及しました。これを使用すると、デバイスとそのメモリ領域についてすぐに知ることができます。検出されたスカラーのデータ型について OpenCL に事前に通知し、それらを忘れないようにすることで、毎回明示的に整数のサイズを設定することを回避する方法。
  
  
• 00:45:00 このセクションでは、講演者は、メモリ空間の命名規則やグローバル メモリとローカル メモリの違いなど、PyOpenCL と PyCUDA におけるいくつかの混乱を招く直感的ではない選択について説明します。また、テクスチャ画像や旅行 ID だけでなく、デバイス、プライベート、ローカル メモリなどのメモリ空間の使用にも焦点を当てています。課題にもかかわらず、講演者は、これらの機能を組み合わせて適切なアルゴリズムを作成することの重要性を強調し、コンポーネントに割り当てられることの有用性を強調しました。
  
  
• 00:50:00 このセクションでは、スピーカーは、PyOpenCL および PyCUDA を使用したプログラミング中にサイン関数やコサイン関数などの要素ごとの演算を使用する利点について説明します。さらに、これらの関数はベクトルをスカラーと同じように扱うことができ、ライトに近いインクリメントからロードおよびストアできるため便利であると説明しています。また、バリアやメモリ フェンスなど、カーネルの起動間およびカーネル内での同期を可能にする同期機能をデバイスに搭載することの重要性も指摘しています。メモリ フェンスは、順序の競合を防ぐためにメモリ操作を事前に制御するためにも重要です。
  
  
• 00:55:00 このセクションでは、講演者が、可変リーフを保管するためのステージング エリアの目的について説明します。ステージング エリアでは、CPU と GPU の間でデータを転送して、中断のない公開操作を行うことができます。講演者は、デバイス固有の操作を最下位レベルでラップして利用できるようにする PyOpenCL についても言及しました。さらに講演者は、コミットする任意の複雑な操作を可能にする「スワップ」操作を漫画で紹介します。講演者は、参加者にさらに質問したり、フックとして公開されている他のデバイス固有の操作を調べたりするよう促します。

[MetaQuotes]

簡単、効果的、効率的: PyOpenCL と PyCUDA を使用した GPU プログラミング (3)

PyOpenCL と PyCUDA を使用した GPU プログラミング (3)

PyOpenCL と PyCUDA を使用した GPU プログラミングに関するビデオ シリーズのこのセクションでは、属性によるコードの最適化、メモリ管理、コード生成、PyOpenCL と PyCuda を使用する利点など、さまざまなトピックについてプレゼンターが説明します。発表者は、実行時に複数の種類のコードを生成する利点を強調し、文字列の置換、構文ツリーの構築、Python と実行言語の利用が柔軟で効率的なコードの作成にどのように役立つかを説明します。発表者は、Python で制御構造を使用する際の潜在的な落とし穴についても警告していますが、アルゴリズムを分析するための抽象的なアプローチが並列性の向上にどのように役立つかを示しています。全体として、このビデオは、PyOpenCL および PyCUDA ライブラリを使用して GPU プログラミングを最適化するための貴重な洞察とヒントを提供します。

このビデオでは、GPU プログラミング用のさまざまなコードを評価して選択するための戦略についても説明しています。コマンドとイベントの出力を分析して、コードが送信された時期と実行時間を特定するプロファイリングが推奨されます。その他の評価オプションには、NVIDIA コンパイラー ログの分析やコードの実行時間の観察などがあります。このビデオでは、PyCUDA および PyOpenCL プログラミングでグループに最適な値を見つけるための検索戦略も取り上げています。講演者は、プロファイラーを使用してプログラムのパフォーマンスを分析することを推奨し、Nvidia プロファイリング パッチの回避策がコードの美しさに及ぼす影響について言及しました。

• 00:00:00 ビデオのこのセクションでは、プレゼンターが OpenCL 仕様をレビューしますが、この仕様はよく書かれていて読みやすいと感じています。さらに、ホストのメモリからデバイスへの転送を開始する際に、ガベージ コレクタがメモリを侵害しないようにするよう視聴者に注意を促しています。プレゼンターは引き続き、暗黙的ワークグループと明示的ワークグループについて説明し、AutoTune がさまざまなバージョンのコードを生成して開発者が最適なものを選択できるようにする方法を示します。最後に、彼はグリッド上の粒子の動きを視覚化する自分が作成したおもちゃを示しました。
  
  
• 00:05:00 このセクションでは、特定の属性を使用してコンパイラーに追加の知識を与え、コードのパフォーマンスを向上させる方法について講演者が説明します。彼は、指定できる 2 つの属性、type と必要なワーク グループ サイズ XY Z について言及しています。Type は、たとえば、コード内の計算の主要な単位が float になることをコンパイラに伝え、コンパイラはどのレジスタを使用するかを決定できます。のようになるでしょう。必要なワーク グループ サイズ XYZ を使用すると、コンパイラーが乗算タスクをより高速に実行し、アクセス パターンを最適化することができます。講演者は、ページロック メモリについても言及しました。これは、プロセッサに近く、ホストに助けを求めずにアクセスできるメモリです。これは OpenGL のコマンド アラート ポスト ポインターの背後に隠されており、GPU プログラミングで役立ちます。
  
  
• 00:10:00 このセクションでは、講演者がメモリと、メモリが GPU とホスト アドレス空間の両方からどのようにアクセスできるかについて説明し、OpenCL にはリニア メモリからのテクスチャリングが存在しないなどのいくつかの制限があるものの、メモリが OpenCL と CUDA でどのように機能するかに注目します。講演者は、Apple の OpenCL 実装が、デバッグ時に問題となる可能性があるキャッシュなどの機能とどのように異なるかについても言及しました。さらに、この講演者は、伝えられるところによると、Intel は OpenCL を好まず、独自のものを推進している一方、Apple はゾウの耳を嘆くために強力な武器を与えていると指摘しています。最後に、講演者は、AMD の GPU 実装をチェックする価値があることを示唆しています。特に、より多くの浮動小数点パワーを必要とする超トップヘビーな作品の場合です。
  
  
• 00:15:00 このセクションでは、講演者はコード生成について説明します。これには、コードをさまざまな状況に適応させるために、実行時に複数の種類のコードを作成することが含まれます。コードの生成は、自動チューニングやさまざまなデータ型などのさまざまなユーザー要求への対応など、いくつかの理由から便利なアイデアです。講演者は、Python がテキスト処理を実行してコードを生成する優れた方法であることを示唆しています。
  
  
• 00:20:00 このセクションでは、講演者はコードの緊密な内部ループに柔軟性をもたらす方法について説明します。彼は、ライブラリを作成するときは、コードが緊密な内部ループ内にある時点で柔軟性を持たせることが重要であると説明しています。彼は、この柔軟性を実現するための 3 つの主な方法、つまり文字列の置換、構文ツリーの構築、およびコードの生成について述べています。講演者はまた、Python と PyOpenCL や PyCUDA などの実行言語を組み合わせて使用すると、各言語の長所を活用し、滑りすぎないコードを構築する合理的な方法を作成できることにも言及しました。最後に、線形代数用の NumPy ライブラリの利点と、それがランタイム コジェネレーションに加えてどのように役立つかについて説明します。
  
  
• 00:25:00 このセクションでは、講演者が GPU プログラミング用の 2 つの Python ライブラリである PyOpenCL と PyCuda を使用する利点について説明します。これらのライブラリでは、型を任意に混合することができ、演算のベクトル化を効果的に処理できます。式の評価を操作する場合、これらのライブラリは要素ごとのカーネルと呼ばれる機能を使用します。これにより、一時配列を作成してその後破棄する必要がなくなります。 PyOpenCL と PyCuda は、要素ごとの累積削減などのデータ並列操作の機能も提供し、ホルダー全体で合計するような操作を実行できます。講演者は、これらのライブラリを使用すると、操作を並列または順次に実行しながら、データ型のさまざまな組み合わせをすべて簡単に処理できるようになると結論付けています。
  
  
• 00:30:00 このセクションでは、非効率を引き起こす可能性があるスカラーを前後に転送する代わりに、GPU 上にスカラーを残すことの利点についてプレゼンターが説明します。また、Web ページを生成し、コード スクリプト内のさまざまなキーワードを置き換えることができるテンプレート エンジンについても説明します。発表者は、これらのテクニックは魔法ではなく、プログラマーにとって大きなメリットとなるシンプルで便利なツールであることを強調します。
  
  
• 00:35:00 このセクションでは、プレゼンターは、コード生成プロセスを簡略化するためのテンプレート エンジンの使用について、プロセスがどのように機能するかの例を示して説明します。テンプレート エンジンでは、ドル記号の間で Python 式を使用できるため、ループを展開して展開を作成するのに役立ちます。結果として得られる出力はソース コードであり、手動で CL に入力する必要があります。プレゼンターは、プロセスを理解しようとする聴衆からの質問に答えます。
  
  
• 00:40:00 このセクションでは、講演者は Python がサポートする制御構造の可用性について説明しますが、これはプログラマが注意しないと首を吊る大きな危険をもたらすことになると警告しています。彼らは続けてリダクションの例について話し、PyOpenCL にはすべての新しい夜を無視または含めることができる Python 機能があるため、任意の可能性でコードを生成する方法を説明します。彼らは、PI は構文ツリーを開くため、このコピー アンド ペースト方法を実行することはほとんど正当化できないと結論付けています。
  
  
• 00:45:00 このセクションでは、ユーザーがコードを構造的に生成することによって適切に構造化された方法でタスクを実行すると、プロジェクトの特定の部分を構築する場合には機能する可能性がありますが、プロジェクトの構築には適さない可能性があると講演者が説明しています。プロジェクト全体。講演者は続けて、ベクトルの加算と削減を行う方法の例について説明します。これは、最初の 2 つの関数、次に結果に対する別の関数として見なされ、ツリーベースのアプローチを使用して実装されます。次に、ユーザーは、実行して待機する作業の量を決定するよう求められ、その後、すべてがどのように機能するかがグラフで表示されます。
  
  
• 00:50:00 このセクションでは、以前のコード バージョンの並列処理を改善して効率を高める方法について講演者が説明します。彼らは、抽象的なアプローチを使用して作業とワークロードに基づいてアルゴリズムを分析し、タスクの並列度を特定することを提案しています。彼らは、ワーカーのサイズと依存関係に基づいてランタイムのバランスをとり、並列処理を改善するという同社の目標について言及しています。また、変数、数式、直接リデュース式を含む、リダクション コードの最終バージョンの例も示しています。次に、パフォーマンスと二重サポートを向上させるコード生成をデモンストレーションします。
  
  
• 00:55:00 このセクションでは、講演者は、特定の項目数のコードを生成する方法の例を示しながら、PyOpenCL と PyCUDA を使用したリダクション式の実装について説明します。彼らは、PyCUDA でのテンプレート メタプログラミングの使用と、それがいかに理解しにくいかについて言及しています。講演者は、PyOpenCL と PyCUDA は単一のソースから冗長性なくさまざまなコードを生成できるため、有用なツールであると主張します。
  
  
• 01:00:00 ビデオのこのセクションでは、講演者が GPU プログラミング用のさまざまなコードを評価して選択する方法について説明します。彼らは、コマンド Q を使用して有効にできるプロファイリングを使用し、コマンドとイベントの出力を分析してコードがいつ送信され、どのくらいの時間実行されたかを判断することを提案しています。その他の評価オプションには、NVIDIA コンパイラー ログの分析、提供された金額の計算、コードの実行時間の観察などがあります。評価するコードの数が 1 回の昼休みで実行できる量を超える場合、徹底的な検索を実行するか、Mike Rita のコンパイラ キャッシュによって提供されるような直交検索方法を使用することを提案しています。
  
  
• 01:05:00 このセクションでは、講演者が PyCUDA および PyOpenCL プログラミングでグループに最適な値を見つけるための検索戦略について説明します。この戦略には、グループを見つけ、すべての選択肢を書き留め、ローカルのターゲット検索を実行することが含まれます。講演者はまた、人々が検索するもののほとんどは比較的単純であり、コードを最適化する際には専門家の意見が貴重である可能性があることを共有しました。講演者は、プロファイラーを使用してプログラムのパフォーマンスを分析することを推奨し、Nvidia プロファイリング パッチの回避策によりコードがきれいではない可能性があると述べました。

[MetaQuotes]

簡単、効果的、効率的: PyOpenCL と PyCUDA を使用した GPU プログラミング (4)

PyOpenCL と PyCUDA を使用した GPU プログラミング (4)

このビデオ シリーズでは、PyOpenCL と PyCUDA を使用した GPU プログラミングに関連するさまざまなトピックを取り上げます。講演者はコード例を共有し、開発サイクル、コンテキストの作成、および 2 つのツールの違いについて説明します。また、衝突検出、不連続ガラーキン法、偏微分方程式の変分定式化、行列ベクトル乗算の最適化についても触れています。さらに、講演者はマトリックス積のコンピューティングの課題について語り、メモリ帯域幅の観点から CPU と GPU のパフォーマンスの違いを強調します。このビデオは、PyOpenCL と PyCUDA を使用する際のパフォーマンスの最適化の重要性を強調して締めくくられています。

このビデオでは、スクリプティングとランタイム コージェネレーションを PyOpenCL および PyCUDA と組み合わせる利点についても説明しています。講演者は、このアプローチによりアプリケーションのパフォーマンスが向上し、時間ステップの困難が軽減されると説明しました。 Maxwell のソリューション プレーンと吸入パワーのデモンストレーションでは、その利点が明らかでした。講演者は、これらのツールを組み合わせて使用することは素晴らしいアイデアであり、さらなる探求の可能性があることを示唆しています。

• 00:00:00 このセクションでは、講演者は PyOpenCL に似ていますが、GPU プログラミング用に PyCUDA を使用したコードを共有します。彼はデバイスのコピーにメモリを割り当て、要素の乗算を実行するカーネルを示しています。また、複数のデバイス アドレスを持つ方法と、PyOpenCL と比較した PyCUDA の機能についても少し触れています。最後に、スパース行列ベクトルの計算と、共役勾配が内部プロセスに基づいて収束できるかどうかをどのように決定できるかについて説明します。これにより、データが CPU と GPU の間で送受信されている間もコンピューティングを続行できます。
  
  
• 00:05:00 このセクションでは、GPU プログラミング用にコンパイルされたコードではなくスクリプト言語を使用する開発サイクルと、前者の欠点について講演者が説明します。彼らは、コンパイルされたコードはコンパイル中にバグを見つけてパフォーマンスを向上させるのに役立ちますが、スクリプト言語ではそれができないと説明しています。しかし、彼らは、PyCUDA および PyOpenCL パッケージを使用すると、コンパイラを呼び出して呼び出し間の待ち時間を回避できるため、この問題を解決できると主張しています。さらに、ランタイム API とドライバー API の区別と、ランタイム API ライブラリが動作するコンテキストを作成できるようにする要件についても言及しています。
  
  
• 00:10:00 このセクションでは、講演者が PyOpenCL と PyCUDA の違いについて説明します。どちらのツールのコンテキスト オブジェクトもさまざまな方法で作成できます。ただし、ユーザーがカーネルを開発しやすくするためのドキュメントが両方とも利用可能です。講演者は、マイクロベンチマークを使用してパフォーマンスをモデル化し、スマート コードを作成する際のパフォーマンスを最適化することを奨励します。次に彼らは、さまざまな線形代数問題に対してうまく機能するような方法で衝突検出を定義する方法を示します。
  
  
• 00:15:00 このセクションでは、講演者は、距離を捉えるには不十分なプリンシパルを指定するために使用されるモデルについて説明しますが、すべてを捉えるには十分ではないことを認めています。次に、データを共有メモリにロードし、カーネルの可能性を反復処理するためのコードを共有します。講演者は、特定のソリューションの最適化と、ループ内で変数を潜在的に再利用する方法について話します。次に、時間依存の保存結合に使用される有限要素法である不連続ガラーキン法について説明します。この方法では、部分ごとに積分し、要素全体にわたる境界項を取得します。要素の境界を越えて積分することも選択できます。
  
  
• 00:20:00 このセクションでは、テスト関数と解空間には不連続性があるため、講演者は政府インターフェイスのインターフェイスで 2 つの異なる有効な値をどのように扱うかという課題について説明します。講演者は、有限体積法用に開発されたリーマンソルバーの理論を使用することを提案しています。保存則の原理を解き、境界面に沿って 2 つの値のいずれかを選択することにより、弱いフォルマンタを作成できます。このアプローチにより、方程式を解く際に、異なる値間のコミュニケーションが可能になります。数学的には使用できるさまざまなスキームがありますが、リーマン ソルバーを使用すると方程式を解くことができ、解空間に収まるようになります。
  
  
• 00:25:00 このセクションでは、講演者は PDE の変分定式化の定式化について説明します。これには、基底関数を置き換えて要素ごとの行列を導入することが含まれ、結果として得られる内積ビューが質量行列につながります。また、非常に単純なスキームに対して要素ごとに実行できる質量行列の反転と、局所的に高密度のデータに適しており、一般に高精度なスキームとして使用されている EG を使用したスキームの簡略化についても説明します。 -注文方法。
  
  
• 00:30:00 このセクションでは、講演者は、GPU プログラミングに PyOpenCL と PyCUDA を使用することが魅力的な選択肢となる、高次の使用による計算強度について説明します。線形保存則を扱う場合、その複雑さに基づいて特定の選択を行う必要があり、中程度の港を狙う場合、ビジネスはより管理しやすくなります。漸近実行時間は要素ごとに 2 つの行列ベクトル積によって支配され、特定の計算はテンソル積要素よりも収益性が高くなります。使用される近似空間はグローバル ビレッジ空間の周囲でローカルなものであり、テンソル積構造を利用しても何の利点もありません。
  
  
• 00:35:00 このセクションでは、ビデオでは、さまざまなワーカー間でワークロードを分割することによって行列とベクトルの乗算を最適化する方法を説明します。講演者は、メモリ使用量やメモリ アクセスの合体などの要素を考慮して、ワーカーごとに 1 つの要素を使用するか、ワーカーごとに複数の要素を使用するかのトレードオフについて説明します。また、要素ごとの粒度で計算するかグループ粒度で計算するかの選択や、データの再利用と並列処理のバランスをとる方法についても検討します。このビデオは、これらの決定はマトリックス サイズや出力バッファ サイズなどのさまざまな要因に依存すると述べて締めくくられています。
  
  
• 00:40:00 PyOpenCL と PyCUDA を使用した GPU プログラミングに関するビデオのこのセクションでは、講演者が計算の粒度、および 70 を満たす計算に必要な粒度の最小レベルについて説明します。これにより、この倍数でエリア パディング要件が満たされます。他の計算に適用される最小レベルの粒度。コードのパフォーマンスの側面と柔軟性の側面について議論され、講演者はボックスのサイズに関連して並行して実行される一連の処理を示すグラフを提示し、コードのパフォーマンスを向上させることの永続的な価値を強調します。ハードウェアに依存することになります。変動定式化と磁束項も CS の観点から強調表示されます。
  
  
• 00:45:00 このセクションでは、講演者は、数学的表記法で書かれた論文からタイトな内部ループを転写し、それをコードに実装するという課題について説明します。この課題に対処するには、実装は論文の数学的表記と厳密に一致する必要があります。さらに、実行されたコードとユーザーのコードの間に思考の層があると、コード生成の無視できない利点が得られます。講演者は、PyOpenCL と PyCUDA を使用して高性能コードを作成でき、そのパフォーマンスはハイエンドで手動で調整された実装に匹敵すると説明しました。また、GTX 280 のメモリ帯域幅を超えており、追加のキャッシュを使用するとパフォーマンスが向上することも指摘しています。
  
  
• 00:50:00 このセクションでは、講演者はメモリ空間が限られているために行列積を計算する際の課題について説明します。計算効率にもかかわらず、メモリはすべての作業を保存するには十分ではないため、研究者は行列をより小さなビットに分解して演算を実行する必要があります。彼らはまた、短いデータセットと太いデータセットでうまく機能する行列積は、GPU 用に最適化する人がいないため、GPU システムで調整するのが簡単ではないことも強調しています。 CPU は短いデータセットの自明なトリプル ループ行列をより効率的に処理できますが、GPU システムはさらに優れており、16 個の GPU は 64 台の上級裁判所 PC と比較して高速に実行されます。
  
  
• 00:55:00 このセクションでは、講演者がメモリ帯域幅の観点から CPU と GPU のパフォーマンスと現実世界のシナリオの実際的な比較について説明します。また、実用的な目的では、マシンに追加されたコアの数ではなく、実際のパフォーマンスを理論上のピーク パフォーマンスと比較する方がよいことも強調しています。講演者は、倍精度を使用しながらパフォーマンスを向上させる可能性についても話し、計算の精度を損なうことなく、より良い結果を達成するために計算を操作する可能性についても言及しています。このセクションは、PyOpenCL と PyCUDA を使用した GPU プログラミングにおける時間統合とアクターに関連する重要な質問のいくつかを講演者が強調して終了します。
  
  
• 01:00:00 ビデオのこのセクションでは、講演者がスクリプティングとランタイム コージェネレーションを PyOpenCL および PyCUDA と組み合わせて使用する利点について語ります。彼は、ビデオで見られる Maxwell ソリューション プレーンと吸気パワーで実証されているように、タイム ステップの痛みを軽減したり、アプリケーションのパフォーマンスを向上させたりするなど、複数の利点が得られると説明しています。同氏は、これらのツールを組み合わせて使用することは素晴らしいアイデアであり、できることは確実にあると述べて締めくくりました。

[MetaQuotes]

Par Lab Boot Camp @ UC Berkeley - GPU、CUDA、OpenCL プログラミング

Par Lab Boot Camp @ UC Berkeley - GPU、CUDA、OpenCL プログラミング

このビデオでは、講演者が主に CUDA に焦点を当て、OpenCL を含む GPGPU 計算の概要を説明します。 CUDA プログラミング モデルは、GPU ハードウェアをよりアクセスしやすく、本質的にスケーラブルにすることを目的としており、さまざまな程度の浮動小数点パイプラインを備えたさまざまなプロセッサ上でのデータ並列プログラミングを可能にします。この講義では、CUDA プログラムを作成する構文、CUDA プログラミング モデルのスレッド階層、CUDA メモリ階層、メモリの一貫性、メモリ操作の順序付けを強制するためのメモリ フェンス命令を使用する必要性、および並列処理の重要性について詳しく説明します。 CPU と GPU を備えた最新のプラットフォームでのプログラミング。最後に、講演者は OpenCL について説明します。OpenCL は、Chronos などの組織によって標準化され、Apple などのさまざまなハードウェア ベンダーとソフトウェア ベンダー間のコラボレーションが関与する、より実用的で移植可能なプログラミング モデルです。

ビデオの講演者は、CUDA と OpenCL プログラミング言語の違いについて説明しています。同氏は、両方の言語には類似点があるが、CUDA の構文がより優れており、成熟したソフトウェア スタックと産業での採用により、より広く採用されていると述べています。対照的に、OpenCL は移植性を目指していますが、パフォーマンスの移植性が提供されない可能性があり、その採用に影響を与える可能性があります。ただし、OpenCL は複数の企業の支援を受けている業界標準です。さらに、講演者は CPU と GPU をプログラミングする方法論と、Matlab をラップして GPU 上で実行する Jacket の使用についても話します。講演者は最後に、参加者のフィードバックに基づいてプログラムが毎年どのように変化するかについて話し、参加者にパーラボを訪問するよう勧めました。

• 00:00:00 このセクションでは、講演者が自己紹介をし、主に CUDA と OpenCL を含む GPGPU 計算に関する講義の議題の概要を説明します。彼は、GPU ハードウェアの概要と、グラフィックス専用のプログラム不可能なユニットから、CUDA と OpenCL の導入による、より強力で柔軟なプログラム可能なユニットへの進化について簡単に説明します。 CUDA プログラミング モデルは、GPU ハードウェアをよりアクセスしやすく、本質的にスケーラブルにすることを目的としており、さまざまな程度の浮動小数点パイプラインを備えたさまざまなプロセッサ上でのデータ並列プログラミングを可能にします。
  
  
• 00:05:00 このセクションでは、講演者は、汎用プログラマが SIMD ハードウェアにアクセスできるようにするという目標について説明します。これには、スケーラビリティを考慮した方法で多くの独立した計算ブロックを表現する必要があります。講演者は、CUDA プログラムを作成する構文を詳しく説明します。これには、GPU が持つハードウェアへのアクセスと、実際の GPU 上で sindi で実行される複数命令複数データ スレッドの抽象化の使用が含まれます。 CUDA メモリのコピーは、ホストとデバイス間の通信の基本的な方法として強調され、講演者は、通信はシステム内の PCI Express リンクを介して行われるが、これは比較的遅いため、最適な通信を行うにはデータ転送を最小限に抑える必要があると指摘しました。パフォーマンス。ベクトル コンピューティングの簡単な概要も説明します。
  
  
• 00:10:00 このセクションでは、ベクトル加算用の標準 C++ コードを並列 CUDA プログラムに変更する方法をビデオで説明します。タグを追加すると、プログラムは GPU 上で実行できるようにコンパイルされ、スレッドはブロック インデックスとスレッド インデックスを使用して、各スレッドが処理する配列の要素を決定します。このビデオでは、単純な CUDA プログラムを動作させるのは比較的簡単ですが、パフォーマンスの最適化には追加の労力が必要であるとも述べています。さらに、このビデオでは、CUDA ソフトウェア環境、CUDA プログラミング モデルのスレッドの階層、ストリーミング マルチプロセッサで構成される GPU アーキテクチャの概要を説明します。
  
  
• 00:15:00 ビデオのこのセクションでは、講演者が GPU 上で並列実行されるグリッドとスレッド ブロックの構造について説明します。グリッドは最大 32 個のスレッド ブロックのセットであり、各スレッド ブロックは最大 1,000 個の CUDA スレッドを実行できます。各 CUDA スレッドは、独自のプログラム状態を持つ軽量で独立した実行コンテキストであり、GPU DRAM の任意のアドレスからロードできます。さらに、32 個の CUDA スレッドのグループがワープを形成します。これはロックステップで実行され、高帯域幅のメモリ アクセスに不可欠です。講演者は、ワープはパフォーマンス最適化の詳細であるが、実行ハードウェアの効率を最大化するために重要であると説明します。
  
  
• 00:20:00 このセクションでは、講演者が、CUDA を使用して NVIDIA GPU 用のコードを作成するための基本的な構成要素について説明します。スレッド ブロックは、指定されたデータ サイズに基づいて、アクセスできる CUDA スレッド、レジスタ、および L1 キャッシュの数を動的に構成できる仮想化されたマルチスレッド コアに似ています。通常、スレッド ブロックには中程度の粒度のデータ並列タスクが含まれており、ブロック内のすべてのスレッドは同じブロック インデックス識別子を共有します。ブロック内のスレッドは、バリアのような組み込みを介して同期したり、高速なオンチップ共有メモリを介して通信したりできます。グリッドはスレッド ブロックのセットであり、グリッド内のすべてのスレッド ブロックは同じエントリ ポイントを持ち、ブロック インデックス番号だけが異なります。プログラムはブロック実行のインターリーブに対して有効である必要があり、GPU 全体を占有するためにグリッドごとに多くのスレッド ブロックを用意することをお勧めします。スレッド階層の最上位レベルはストリームです。これはオプションですが、複数のカーネル関数を同時に実行するために必要です。
  
  
• 00:25:00 このセクションでは、講演者は、レジスタ ファイルのバッキング ストアとして機能するスレッドごとのローカル メモリから始めて、CUDA メモリ階層について説明します。各 CUDA スレッドは、スレッド プログラミング モデルに合わせたメモリ システムを使用して、コンパイル時に指定された構成可能な数のレジスタにプライベート アクセスできます。また、16 キロバイトの L1 キャッシュと 48 キロバイトのソフトウェア管理のスクラッチパッドとして使用したり、その逆にカーネル呼び出し時に動的に構成できるスクラッチパッド メモリもあります。グローバル メモリはオンチップ メモリよりもはるかに高価であり、サイクル数の点で 100 倍以上の遅延があります。レジスタとオンチップ メモリはプログラムの状態を保持し、グローバル メモリは永続的な状態を保持します。
  
  
• 00:30:00 このセクションでは、講演者が GPU と CPU のメモリ階層について説明します。 GPU は、グローバル DRAM と比較して L1 キャッシュ全体の帯域幅が高く、モダー サイズの GPU では DRAM に 1 秒あたり約 100 ギガバイトのアクセスが可能です。さらに、64 キロバイトの定数メモリや CUDA テクスチャ メモリなど、場合によっては役立つメモリ階層のコンポーネントもあります。複数の GPU を使用でき、それぞれが CPU メモリとは別の独立したグローバル メモリを持ちます。 CUDA メモリ階層の最も重要な側面は、高速オンシップ共有メモリを使用したスレッド ブロック内の通信です。これには、スレッド ブロック内のスレッドを同期するために同期スレッド関数を使用する必要があります。
  
  
• 00:35:00 このセクションでは、講師は、共有メモリを使用して行列を転置するコード スニペットを提供します。これは、メモリ帯域幅よりも大幅に高い同時実行性を表現するために重要です。共有変数は on-begin と end のタグを介して静的に宣言できますが、配列全体を割り当て、整数インデックスを介して extern を使用して動的に宣言することもできます。スクラッチ パッドと同期スレッドは、スレッド間で共有されるデータを除き、スレッド ブロック内のほぼすべての通信に不可欠です。共有メモリにアクセスするとバンクの競合が発生し、パフォーマンスが大幅に低下する可能性があります。この問題は、タイムラグをまったく引き起こすことなくバンクにアクセスできるように、ポインタをインターリーブすることで軽減できます。最後に、講師はアトミック メモリ操作について話します。これにより、コストはかかりますが、ユーザーはプログラム内のすべてのスレッドから同じメモリ位置にアクセスできるようになります。
  
  
• 00:40:00 このセクションでは、講演者はメモリの一貫性と、メモリ操作の順序を強制するためにメモリ フェンス命令を使用する必要性について説明します。ハードウェアは複数のスレッドからのアクセスを自動的に同期しますが、プログラマがメモリ フェンス命令を使用しない場合、一部の追加は有効にならない可能性があります。講演者は、交換、比較、交換などの特定の操作がスピン ロックの実装にどのように役立つかについても説明します。彼らは、メモリシステムがどのように高いパフォーマンスを実現するかにより、メモリアクセスが実行されたのと同じ順序でグローバルに現れるとは想定できないと警告している。最後に講演者は、CUDA がどのように機能的に寛容になるように設計されているかについて触れていますが、パフォーマンスを引き出すにはハードウェア実装が重要です。
  
  
• 00:45:00 このセクションでは、講演者は、単一のストリーミング マルチプロセッサに相当するスレッド ブロックの概念と、スレッド ブロックがレジスタ ファイル、L1 キャッシュ、命令キャッシュ、テクスチャ ユニットなどの複数のメモリ リソースにどのようにアクセスするかを説明します。 。複数のスレッド ブロックで構成されるグリッドは、GPU 上の複数のストリーミング マルチプロセッサを利用できますが、多くの場合、1 つのグリッドで GPU 全体が飽和状態になります。ただし、グリッドが十分に大きくないシナリオでは、GPU 全体をカバーするために、いくつかのストリームが複数のグリッドを並行して実行する必要があります。機能ユニットと PCI Express 転送の実行レイテンシーを隠すために、講演者は、共有メモリと L1 キャッシュを積極的に使用しながら、同じスレッド ブロック内の複数のワープを独立して実行することを提案しています。メモリ使用率がパフォーマンス チューニングに影響を与えるため、パフォーマンスを最適化するには、メモリからロードされたすべてのバイトを少なくとも 10 ～ 20 回再利用することが不可欠です。スピーカーは、メモリ使用率を改善する方法についてのさらなるガイダンスを提供します。
  
  
• 00:50:00 ビデオのこのセクションでは、講演者が CPU、GPU、その他のプロセッサを備えた最新のプラットフォームにおける並列プログラミングの重要性について説明します。彼は、すべてのプログラムは必要なすべての計算リソースを活用する必要があり、世界は多くの点でより不均質になってきていると述べています。同氏はまた、保守可能な並列ソフトウェアを作成するために並列ハードウェアにアクセスするための業界標準と、並列コードを作成するための SDK 内の高レベルのプログラミング環境の必要性を強調しました。さらに、彼はさまざまな失敗したプログラミング言語について言及し、プログラムは美しくあることに焦点を当てるのではなく、むしろ優れたプログラミング モデルを見つけることに重点を置く必要があると述べています。講演者は OpenCL についても話し、美しくならないよう努めており、CUDA の代替手段を提供していると述べています。
  
  
• 00:55:00 このセクションでは、GPU はさまざまなハードウェアで実行でき、ソフトウェアの寿命が長い必要があるため、講演者は GPU のプログラミング モデルにおける実用主義と移植性の重要性について説明します。これは、Nvidia のハードウェア上でのみ実行され、非常に特殊で型指定されている CUDA にとって問題となるため、一部の人にとっては採用が困難です。一方、OpenCL は、より実用的で移植可能なプログラミング モデルであり、Chronos などの組織によって標準化されており、Apple などのさまざまなハードウェア ベンダーとソフトウェア ベンダー間の協力が必要です。 OpenCL の概要は、プラットフォームのモデリングという点では CUDA に似ており、コマンド キュー、作業項目、および同様のメモリ モデルを使用します。ただし、OpenCL の構文ははるかに複雑で、さまざまな操作のための数百の異なる関数があります。ベクトル追加の例は、カーネル関数の OpenCL コードを使用して再度示されます。これには、for ループの削除、カーネル タグの追加、およびポインターへの追加タグの追加が含まれます。
  
  
• 01:00:00 このセクションでは、講演者が CUDA と OpenCL の違いについて説明します。どちらもユーザーがさまざまな種類のハードウェアをプログラムできるようにします。類似した構文を共有していますが、CUDA はより成熟したソフトウェア スタックを提供し、産業での採用が拡大し、その結果としてアプリケーションの範囲が広がります。一方、OpenCL は移植性を目指していますが、パフォーマンスの移植性が提供されない可能性があり、対応しなければ導入が妨げられる可能性があります。それにもかかわらず、OpenCL は業界標準であり、複数の企業の支援を受けているため、開発者はそのソフトウェアへの投資に自信を持っています。 OpenCL は CUDA のライバルであるにもかかわらず、Nvidia は依然として OpenCL をサポートしており、講演者は Nvidia が OpenCL 用に最適化されたコードを生成しない可能性があることを明言しました。
  
  
• 01:05:00 このセクションでは、講演者が OpenCL と CUDA プログラミング言語の類似点と相違点について話します。どちらも類似点がありますが、CUDA プログラミング言語はより優れた構文を提供しており、それを使用するために OpenCL API の知識は必要ありません。 NVIDIA が OpenCL コンパイラをオープンソースにしないことを選択したため、コンパイラが異なる主な理由は完全に実用的です。 CPU と GPU をプログラミングする方法論は、GPU をターゲットにし、スレッド ブロック内のすべての並列化を取り除き、スレッド ブロックを単一の CPU コアで実行される P スレッドまたは openmp スレッドに変換し、ワープをSSE の指示。講演者は、Matlab をラップして GPU 上で実行する Jacket についても話しますが、Jacket のようなプログラムが CUDA の可能性を最大限に活用できる割合をパーセントで判断するのは困難です。
  
  
• 01:10:00 このセクションでは、講演者が参加者のフィードバックに基づいてプログラムを毎年どのように変更しているかについて説明します。彼らは、参加者が気に入った点、気に入らなかった点、改善できる点を尋ねるフォームを送信する予定です。登壇者が集まってステージ上でカジュアルなディスカッションやディベートを行うパネルを設置します。参加者からもパーラボを見たいという要望があったので、ぜひ足を運んで実際にそのスペースを見てほしいとのこと。最後に、講演者は全員に感謝の意を表し、学期の良い休息を祈ります。

[MetaQuotes]

Lambert Labs で学ぶ: OpenCL とは何ですか?

OpenCLとは何ですか?

OpenCL に関するこのビデオでは、発表者がグラフィックス プロセッシング ユニット (GPU) とグラフィックス プログラミングでのその使用法を紹介し、その後、GPU を汎用コンピューティングに使用する方法を説明します。次に、OpenCL は、開発者がプラットフォームに依存せずにベンダー固有の最適化を実現できる API として紹介され、講演者は最適な GPU パフォーマンスを達成するためのタスク設計の重要性を強調しました。 OpenCL での同期について説明し、C 系言語を使用したサンプル GPU プログラムを示します。また、講演者は、OpenCL がどのように計算を大幅に高速化できるかを実証し、GPU を使用するためのアドバイスを提供します。

• 00:00:00 このセクションでは、プレゼンターは、グラフィックス プロセッシング ユニット (GPU) が従来どのように使用されてきたかについて説明します。これは、特殊で高性能なハードウェアを必要とするリアルタイムまたはプリレンダリング アプリケーションでの画像のレンダリングなどのグラフィックス プログラミングです。汎用 GPU プログラミングは、計算負荷が高く、高いパフォーマンスを必要とするグラフィックス以外のタスクにグラフィックス カードを使用するものとして説明されています。 OpenCL は、すべてのベンダー固有のフレームワークと実装に共通のインターフェイスを提供する API として導入され、プラットフォームに依存せずにベンダー固有の最適化を行うことが可能になります。これは、GPU が高度に専門化されプラットフォームに依存する部分であるため便利です。ハードウェア。
  
  
• 00:05:00 ビデオのこのセクションでは、講演者が GPU の最適化に適したタスクの機能について説明します。タスクを、異なるスレッドで同時に実行できる小さなサブタスクに分割することが重要です。複数のスレッドで実行するには、サブタスクの形状と構成がほぼ同じである必要があります。ワークグループ間での同期は必要ないため、タスクは同期に関して互いに独立している必要があります。このビデオでは、サブタスクが互いに分岐するほどパフォーマンスが低下し、CPU を使用した方が高速になる可能性があることを強調しています。したがって、GPU の処理能力を活用するには、タスクを慎重に設計し、最適化する必要があります。
  
  
• 00:10:00 このセクションでは、OpenCL における同期の主な方法であるバリア関数について講演者が説明します。この関数は、すべてのスレッドが続行する前に到達する必要があるチェックポイントとして機能します。非常にパフォーマンスが高いわけではありませんが、すべてのスレッドが適切なタイミングで確実に同期されるようにするために、バリア機能は依然として重要です。講演者は続けて、C によく似た言語で書かれたサンプル GPU プログラムを提示し、さまざまなパラメーターとコードのロジックについて説明します。最後に、講演者は、Python と OpenCL を使用して最初の 100 万個の平方数を計算するプログラムのベンチマーク テストを実行します。
  
  
• 00:15:00 このセクションでは、スピーカーは、100 万個の数値とそれらのそれぞれを平方する配列を受け取る Python スクリプトについて説明します。次に、Python のマルチプロセッシング ライブラリを調べて、サイズ 5 のスレッド プールを作成しましたが、それを並列実行すると実際に計算が遅くなることがわかりました。最後に、プログラム メモリに文字列として保存されている C カーネル関数を使用する OpenCL の例を示し、カーネル関数を実行するために必要な定型コードを調べます。 OpenCL サンプルの実行には 1 ミリ秒かかります。これは、以前の Python 実装から大幅に改善されました。
  
  
• 00:20:00 このセクションでは、GPU プログラミングにより、所要時間が 160 ミリ秒から約 1 ミリ秒に短縮され、コードのボトルネックが大幅に高速化できると講演者が説明しています。これは 100 倍の高速化です。この種の高速化は大きな違いを生む可能性があり、コードのボトルネックを「作るか壊すか」は 2 桁大きくなります。開発者が GPU を操作するための最良の方法は、リモート マシンで作業するのではなく、ローカル GPU にアクセスすることです。ただし、Google Cloud ではクラウド内の GPU へのアクセスが提供されます。 OpenCL はさまざまな GPU ハードウェアに依存しないため、開発者は GPU ハードウェアに関係なく使用できます。ただし、サブタスク関数は明示的である必要があるため、開発者は GPU を最大限に活用するために問題にどのようにアプローチするかを慎重に設計する必要があるため、サブタスクは慎重に設計する必要があります。

[MetaQuotes]

OpenCL による機械学習の高速化

OpenCL による機械学習の高速化

ウェビナー「OpenCL による機械学習の高速化」では、講演者が機械学習アプリケーション向けに OpenCL に対して実行できる最適化について説明します。講演者の 1 人は、OpenCL と、オープンソースの OneDNN ライブラリを使用した Intel GPU 上のアセンブリをどのように比較したかについて概要を説明しました。 Intel ハードウェア向けの最適化に重点を置いていますが、他のハードウェア向けのインターフェイスも提供し、複数のデータ型と形式をサポートしています。このグループは、OpenCL を使用した機械学習ワークフローの最適化の課題や、一般的な機械学習フレームワークへの OpenCL の統合についても議論します。さらに、異なるフレームワーク間での OpenCL の使用の統合は時期尚早になる可能性があると彼らは指摘しています。最後に、講演者は、特に画像処理アプリケーションで重要な畳み込みなどの特定の主要な演算子について、クアルコムの ML 拡張機能を使用することによるパフォーマンス上の利点について説明します。

「Accelerated Machine Learning with OpenCL」ビデオでは、パネリストがコンピューテーショナル・フォトグラフィーや自然言語処理など、機械学習を採用できるさまざまなユースケースについて話しました。彼らは、研究結果に基づいて機械学習のワークロードを最適化し、スケールアップする必要性を強調しました。さらに、パネリストは、音声が機械学習を使用した高度なユーザー インターフェイスの重要な成長分野であると特定しました。セッションは、ディスカッションに参加してくれたお互いと聴衆に感謝し、アンケートを通じてフィードバックを提供するよう参加者に思い出させて終了しました。

• 00:00:00 ウェビナーのこのセクションでは、Chronos Group の社長である Neil Trevitt が、Chronos コミュニティと機械学習ハードウェアとの間の継続的なコミュニケーションを促進することを目的としたオープン フォーラムである Chronos Machine Learning Forum の概要を説明します。ソフトウェアコミュニティ。 Trevitt 氏は、OpenCL はすでに機械学習と推論の市場で広く使用されており、OpenCL の最近の拡張機能の多くは機械学習と推論の高速化に関連していると述べています。機械学習フォーラムは、開発者が意見を提供し、Chronos がアップデートやロードマップ情報をより広範なコミュニティに提示する機会です。
  
  
• 00:05:00 このセクションでは、Intel の AI アルゴリズム エンジニアである講演者が、オープンソース ライブラリ OneDNN を使用して機械学習ワークロードを最適化するために、OpenCL と Intel GPU でのアセンブリを比較する取り組みについて説明します。同氏の説明によると、彼らのチームは Intel ハードウェア向けの最適化に重点を置いているが、他のハードウェア向けのインターフェイスも提供し、複数のデータ型と形式をサポートしているという。ジャストインタイム コンパイル ベースのアーキテクチャを使用して、問題とハードウェアに基づいて最適な実装を選択し、今後の統合 GPU と既存の統合 GPU の両方を最適化します。彼はさらに、比較の結果と遭遇した問題について話し合い、最適化の決定に導きました。
  
  
• 00:10:00 このセクションでは、講演者が GPU がどのように分割され、ベクトル エンジンと行列エンジンが主要な計算をどのように実行するかについて説明します。講演者は、畳み込みとデータの並べ替えを最適化する方法、およびインテル ハードウェアのサブグループと拡張機能をどのように使用するかについて説明します。 sprv と sickle に拡張機能を追加することで、より簡単なアクセスを可能にする計画があると述べています。また、Intel GPU でのアセンブリ生成に ac plus ライブラリを使用する、アセンブリ側についても説明します。最後に、最適化によって OpenCL で達成できた大幅な高速化について話します。
  
  
• 00:15:00 このセクションでは、講演者が OpenCL とエンジン実装の分析について説明し、OpenCL 実装が特定の条件下で短い読み取り命令と追加の命令を発行したと述べています。ただし、これらの問題は根本的なものではなく、Intel のコンパイラ チームと協力して実装を変更することで解決できると彼らは指摘しています。講演者は、実装のギャップを明らかにするのには役立ちますが、生産性には劣るアセンブリの使用についても説明します。最後に、アセンブリ ジェネレーターの採用について言及しています。これにより、問題に対する最適化変換を指定できる機能により、より高速なコード生成が可能になりました。
  
  
• 00:20:00 このセクションでは、講演者は、指定された 1 つの変換のみを使用して最適化をより効果的に構成する方法について説明します。これは、複数の実装の急増を避けるのに役立ちます。次に、焦点は Balaji Kalidas に移ります。彼は、モバイル デバイスで急速に成長している機械学習の加速を支援するためにクアルコムがサポートしている拡張機能と機能について説明します。 GPU は依然として人気のあるオプションですが、講演者は、モバイル デバイス上で効率的な機械学習を確保するには、消費電力、低レイテンシーのディスパッチ、システム オン チップ上の他のブロックとの同期がすべて対処する必要がある重要な考慮事項であると述べています。講演者は、これらの懸念を解決するために、データのゼロ コピー インポート/エクスポート、Android ハードウェア バッファーと DMA バフのインポート/エクスポートなどの機能について言及しました。
  
  
• 00:25:00 このセクションでは、講演者が CL qcom ml-ops 拡張機能について説明します。これは、GPU での機械学習を op レベルで高速化するための Qualcomm ベンダー拡張機能です。この拡張機能は、コマンド キュー、イベント、バッファーなどの既存の OpenCL 構造を可能な限り使用し、他の OpenCL カーネルと完全に相互運用可能です。拡張機能の主な使用例の 1 つはエッジ トレーニングであり、これにより転移学習、パーソナライゼーション、フェデレーテッド ラーニングが可能になりますが、エッジでのトレーニングの主な制限要因はメモリ フットプリントです。これに対処するために、講演者はテンソル バッチ 1 アプローチについて説明します。これは、テンソル バッチ サイズを 1 に保ち、バッチが完了するまで何度も前方パスと後方パスを実行するように修正されたアプローチを使用します。このアプローチでは、メモリ フットプリントを削減しながら、より大きなバッチ サイズでトレーニングした場合と同じ結果が得られます。
  
  
• 00:30:00 このセクションでは、講演者が機械学習タスクを高速化できるいくつかの OpenCL 拡張機能について説明します。最初に説明した拡張機能は、8 ビットの量子化 DNNS を実装するときに大幅なパフォーマンス上の利点をもたらす 8 ビット ドット積ベンダー拡張機能です。次に説明する拡張機能は、「clq com recordable queues」です。これにより、特殊なディスパッチ呼び出しで再生できる一連の ND 範囲カーネル コマンドを記録できるようになり、重要な CPU 消費電力とディスパッチ レイテンシーが大幅に改善されます。ストリーミング モードの機械学習の使用例。ゼロ コピー、サブグループ操作、浮動小数点アトミック、バッファーからの一般化されたイメージ、コマンド バッファーの記録と再生などの他の拡張機能も機械学習に役立ち、Qualcomm 拡張機能として利用できるか、Chronos から提供されています。
  
  
• 00:35:00 カーネルを個別に送信するよりも、一度に送信できるカーネルのバッチを大きくしたほうが効率的です。ここで、記録可能なキューが登場します。各インスタンス間で変更される引数が 1 つまたは 2 つだけで、カーネルの大規模なバッチの記録と前処理が可能になります。これにより、実装で実行しなければならない作業量が大幅に削減され、CPU パワーが節約されます。さらに、GPU 使用率を最大化し、ディスパッチ間のアイドル期間を最小限に抑えるのに役立ちます。これは、数百のカーネルを順番に実行する必要がある機械学習モデルにとって特に重要です。全体として、記録可能なキューは、OpenCL を使用した機械学習アクセラレーションの効率を向上させるための貴重な拡張機能です。
  
  
• 00:40:00 このセクションでは、グループは、フラッシュだけでなく、バッチ処理の最適な時間とサイズの決定を含む、OpenCL を使用した機械学習ワークフローの最適化の課題について議論します。彼らは、Carbon Queue のようなツールがこれらの問題の解決に役立つと述べています。 OpenCL ではコンパイル時間が大きな障害となっているという問題も議論されていますが、これは解決するのが簡単な問題ではありません。このグループは、生成されるカーネルの数を潜在的に減らすために OpenCL レベルで特殊化定数を使用することを提案していますが、実装には多くの作業が必要です。彼らはまた、パフォーマンスの最適化のための LLVM の使用の可能性についても議論していますが、現在の大きな問題としてコンパイル時間が遅いことを指摘しています。
  
  
• 00:45:00 トランスクリプトのこのセクションでは、講演者が、実行時に機械学習アプリケーションをコンパイルする際の課題と、コンパイル済みのバイナリの使用について説明します。また、MLIR によって提供される可能性のあるソリューション、マルチレベル ソリューション、およびグラフ レベルでの加速との比較についても触れています。講演者らは、ベンダーが提供する拡張機能をいくつかの重要なメタ コマンドに使用できる一方で、グラフ コンパイラーまたは独自のカーネルを作成することをその他すべてに使用でき、両方の長所を活用できることに同意します。
  
  
• 00:50:00 ビデオのこのセクションでは、講演者が、特にモバイル デバイスにおける一般的な機械学習フレームワークへの OpenCL の統合について説明します。彼らは、OpenCL を使用するオープン ソース フレームワークがすでに多数存在し、TensorFlow Lite には良好に動作する OpenCL バックエンドがすでにあると述べています。ただし、OpenCL を汎用フレームワークに統合する場合、汎用実装でパフォーマンスを維持するにはさまざまなベンダーが貢献する必要がある可能性があるため、パフォーマンスとパフォーマンスの移植性が依然として課題であると彼らは指摘しています。彼らはまた、異なるフレームワーク間での OpenCL の使用の統合が時期尚早である可能性があることも示唆しています。
  
  
• 00:55:00 このセクションでは、講演者は、TVM または Tensorflow Lite のみを使用する場合と比較して、Qualcomm の ML 拡張機能を使用するとパフォーマンスが大幅に向上することを説明します。利点は、開発者が独自のカーネルを作成し、それを GPU 用に最適化することにどれだけの労力を費やすかによって異なります。畳み込みなどの特定のキー演算子にも明らかな利点があります。講演者は、今後これらのキーオペレーターを加速させることで、さらなる価値の提供を期待している。このパネルでは、機械学習の高速化に対する需要を促進しているアプリケーション分野についても議論されており、特に画像処理が主要な分野となっています。
  
  
• 01:00:00 ビデオのこのセクションでは、パネリストがコンピュテーショナル フォトグラフィーや自然言語処理などの機械学習のユースケース分野について議論しました。また、機械学習のワークロードを最適化する際の課題と、研究結果に基づいてスケールアップする必要性についても話し合いました。さらに、パネリストは、機械学習を使用した高度なユーザーインターフェイスが重要な成長分野であり、音声もその一部であると指摘しました。最後にセッションは終了し、パネリストはお互いとディスカッションに参加してくれた聴衆に感謝し、モデレーターは参加者にフィードバックのためのアンケートに記入するよう促しました。

[MetaQuotes]

Mandelbulber v2 OpenCL「高速エンジン」4K テスト

Mandelbulber v2 OpenCL「高速エンジン」4K テスト

これは、部分的に実装された OpenCL レンダリング エンジンを備えた Mandelbulber v2 を使用して、飛行アニメーションをレンダリングする試みです。このテストの理由は、長時間のレンダリング中のアプリケーションの安定性と、カメラが表面に非常に近づいたときにレンダリングがどのように動作するかを確認することでした。 OpenCL カーネル コードは単精度浮動小数点数のみを使用して実行されるため、3D フラクタルの深いズームを行うことはできません。このアニメーションを 4K 解像度でレンダリングするのに、nVidia GTX 1050 ではわずか 9 時間かかりました。

[MetaQuotes]

マンデルボックス フライト OpenCL

マンデルボックス フライト OpenCL

これは、Mandelbulber v2 OpenCL alpha バージョンでレンダリングされたマンデルボックス フラクタルのテストレンダーです。

[MetaQuotes]

[3D フラクタル] 予言 (4K)

[3D フラクタル] 予言 (4K)

Mandelbulb3D から 4K でレンダリングされました。