OpenCL タスク スケジューリングの基本概要 | JD Logistics テクニカル チーム

現在、科学技術コンピューティングの需要が劇的に増加しており、CPU-GPU ヘテロジニアス システムに基づくヘテロジニアス コンピューティングが科学コンピューティングの分野で広く使用されており、OpenCL はクロスプラットフォームの特性によりヘテロジニアス コンピューティングの分野でますます普及しています。従来の OpenCL タスク スケジューリングでは、コーディング段階でスケジューリング プランを決定する必要があることが明らかになり、この種の手動スケジューリングは難しく、適応性が低く、非効率であり、リソース競合の問題があります。MultiCL は、OpenCL 標準を拡張することでコマンド キューをデバイスから切り離し、適応型スケジューリングを実現し、さまざまなレベルの開発者にさまざまなスケジューリング方法を提供して、OpenCL スケジューリングの問題を軽減します。

1 OpenCL の基本概要

OpenCL は、異種システムの汎用並列プログラミングのための初のオープンな無料標準であり、CPU、GPU、およびその他のプロセッサにわたる異種ハイブリッド プログラミングに適しています。OpenCL は、効率的な低レベルのプログラミング インターフェイスを作成することにより、ハードウェア、オペレーティング システム、アプリケーションから独立した並列コンピューティング エコシステムの基礎層を実装します。OpenCL は、OpenCL 標準をサポートするホストと異種コンピューティング デバイス間の並列コンピューティングを調整するために使用され、明確なクロスプラットフォーム プログラミング言語を備えています。

OpenCL は、異種システムでのプログラミングの業界標準です。OpenCL は単なるプログラミング言語ではなく、異種システムをプログラミングするための業界標準のフレームワークです。CUDA と比較して、OpenCL プログラムはさまざまなベンダーのハードウェアに移植でき、機能の移植性に優れています。ただし、OpenCL は低レベルの一般的なフレームワークとして、プログラマに多くのハードウェアの詳細を公開するため、プログラムを最適化するための多くのスペースをプログラマに提供できるという利点がありますが、OpenCL プログラムのパフォーマンスが低下する原因にもなります。移植性、つまり同じプログラムでも、移行プロセス中にパフォーマンスに大きな違いが生じます。一方で、プログラマにとっては、タスクの分割やスケジューリングが完全にプログラマに指示されるため、システム全体の動作状況や負荷状況を把握・予測することが難しく、プログラムの効率を最適化することが困難になります。

クロスプラットフォームの異種コンピューティングを実現するために、OpenCL アーキテクチャには次の部分が含まれています。

  1. OpenCL プラットフォーム層: OpenCL プラットフォーム層を使用すると、ホスト プログラムが OpenCL デバイスを検出し、そのデバイスを呼び出して計算に参加させたり、特定のデバイスまたはデバイス グループのコンテキストを作成したりすることができます。
  2. OpenCL ランタイム: OpenCL ランタイムを使用すると、ホスト プログラムが作成された後にそのコンテキスト上で動作できるようになり、OpenCL プログラムに対するソフトウェア サポートが提供されます。
  3. OpenCL コンパイラー: OpenCL コンパイラーは、カーネルお​​よびデバイス拡張情報に基づいて、カーネル ファイルを実行可能ファイルにコンパイルします。コンパイラは、並列拡張に基づいた ISO C99 (ISO/IEC 9899:1999-プログラミング言語) 言語のサブセットをサポートします。OpenCL コンパイラは、ジャストインタイム コンパイルとバイナリ ロードの 2 つの方法で実行可能ファイルを作成できます。

OpenCL アーキテクチャは、プラットフォーム モデル、実行モデル、ストレージ モデル、プログラミング モデルに分類できます。

2 マルチCL

OpenCL 標準では、開発者がプロ​​グラムのコーディング段階で OpenCL プログラムのスケジューリング計画を決定する必要があるため、OpenCL はスケジューリングの難易度が高く、適応性が低く、リソースの競合、効率が低いなどの問題に直面しています。上記の問題を解決するために、Ashwin M らは、SunCL に基づいた OpenCL タスクレベルの並列スケジューリング フレームワークをさらに開発し、クロスベンダーの OpenCL ランタイム サポートを提供しました。MultiCL は、特定のコマンド キューに対するコンテキスト レベルのフル キュー スケジューリング機能とローカル スケジューリング機能を実装しており、これに基づいて OpenCL タスクの動的スケジューリングを実装しています。
OpenCL カーネル スケジューリング戦略はプログラミング モデルに依存します. 開発者はプログラムに含まれるカーネル スケジューリング スキームを事前に明確にする必要があります. OpenCL の適応タスク スケジューリングを実現するために、Ashwin M らは OpenCL API を拡張しました。表 1 に、MultiCL の拡張属性を示します。

表 1 MultiCL 拡張属性

グローバル キュー スケジューリング メカニズムを表現するために、MultiCL フレームワークは、CL_CONTEXT_SCHEDULER によって作成されたコンテキストを使用して、コンテキスト レベルの OpenCL 適応スケジューリングを実装する新しいコンテキスト属性 CL_CONTEXT_SCHEDULER を拡張します。このコンテキストに関連付けられたコマンド キューは、OpenCL デバイスから分離されます。つまり、OpenCL コマンド キューの作成には OpenCL デバイスを指定する必要がありません。これにより、エンコード フェーズでコンテキスト レベルで完了する必要がある OpenCL カーネル スケジューリングの問題が解決されます。OpenCL コンテキスト属性には、ラウンドロビン スケジューリング (ROUND_ROBIN) と適応スケジューリング (AUTO_FIT) という 2 つのグローバル スケジューリング戦略に対応する 2 つのパラメーターが含まれています。ループスケジューリングとは、スケジューラーがトリガーされたときに、コマンドキューを次に使用可能なデバイスにスケジュールすることですが、実際の動作プロセスでは、GPU デバイスが複数のコアの同時実行をサポートしているため、このソリューションはスケジューリングに十分なコンピューティングリソースを持つデバイスを選択します。この方法では、スケジューリングのオーバーヘッドが最小限に抑えられますが、常に最適なキューとデバイスのマッピングが選択されるわけではありません。自動スケジューリング戦略は、MultiCL フレームワークによって提案されたカーネルの事前実行に基づく動的スケジューリング戦略であり、MultiCL フレームワークは動的スケジューリング戦略に基づいて最適なキューとデバイスのマッピングを選択します。

同時に、ローカル スケジューリング戦略を実装するために、OpenCL API コマンドのスケジューリング キュー属性が拡張され、特定のキューが自動スケジューリング モードを選択するか手動スケジューリング モードを選択するかを決定するためにSCHED AUTOまたは SCHED OFFが追加されます。MultiCL フレームワークでは、SCHED_OFF フラグを使用してスケジューリング スキームを手動で指定するオプションがユーザーに提供されます。ユーザーは、コマンド キューを作成するときに SCHED_AUTO フラグを追加して、静的スケジューリング (SCHED_AUTO_STATIC) や動的スケジューリング (SCHED_AUTO_DYNAMIC) などの自動スケジューリングを実装することもできます。コマンド キュー プロパティの変更は、スケジューリングの微調整パラメーターとして使用することを目的としており、さまざまなレベルの OpenCL 開発者向けにさまざまなレベルのスケジューリング戦略が開発されています。豊富な経験を持つ開発者の場合、MultiCL フレームワークによって提供されるコマンド キュー パラメータを直接無視して、すべてのキューを手動でスケジュールすることを選択できるため、開発者は異種システムの基本的な特性に応じてタスク分割とカーネル最適化を実装することが容易になります。開発者、最下層 アーキテクチャをある程度理解している場合は、OpenCL カーネルのロード タイプ (SCHED_IO_BOUND、SCHED_COMPUTE_BOUND など) に応じてシステムのスケジューリング プロンプトとしてコマンド キュー属性を選択できます。 MultiCL フレームワークは、OpenCL カーネル タイプ プロンプトに従ってマイクロ カーネルを構築し、それをスケジュールできます。初級開発者向けには、MultiCL フレームワークが提供する適応動的スケジューリングを使用し、MultiCL ランタイムにカーネル スケジューリング スキームを決定させることができます。このメソッドは実行時に一定のオーバーヘッドをもたらします。

MultiCL 拡張 clSetCommandQueueSchedProperty コマンドは、スケジューラ領域をマークするために使用され、必要に応じてさらにスケジューラ フラグを設定できます。たとえば、次のプロパティを使用します。 clCreateCommandQueue の拡張パラメータ これに応じて、この関数はスケジューリング プランの最適化を容易にします。OpenCL カーネル起動コマンドのパラメータには、コマンド キュー、カーネル オブジェクト、およびカーネルの起動設定が含まれます。自動スケジューリングの便宜を図るため、MultiCL は、カーネル構成パラメーターの設定に使用される新しい OpenCL API コマンド clSetKernelWorkGroupInfo を実装しています。MultiCL フレームワークは、OpenCL カーネル スケジューリング コマンドが追加される前に、カーネルのワーク グループとワーク グループ内の作業項目情報を取得できます。コマンド キューへの追加 MultiCL フレームワークによるカーネル スケジューリングを容易にします。

MultiCL ランタイム設計を図 1 に示します。

SCHED_OFF フラグを使用して作成されたユーザー コマンド キューは、選択したデバイスに静的にマッピングされます (マッピング スキームはコーディング段階で開発者によって指定されます)。一方、SCHED_AUTO フラグを使用して作成されたコマンド キューは、MultiCL によって自動的にスケジュールされます。MultiCL フレームワークが OpenCL カーネル起動コマンドをキューに追加した後、コマンド キューが SCHED_OFF フラグを使用して作成されたコマンド キューである場合、静的スケジューリング スキームが使用されます。MultiCL ランタイムは、SunCL ランタイムの静的スケジューリング スキームを保持します。静的ハードウェアは開発者向けに予約されています エンコーディング スケジューリング機能。コマンド キューが SCHED_AUTO フラグを使用して作成された場合、適応スケジューラによってデバイス プール内のデバイスにマッピングされます。上記のスケジューリング プロセスには、デバイス静的分析 (clGetPlatformIds のデバイス情報読み取りフェーズで実行)、カーネル静的分析 (clBuildProgram、clCreateProgramWithSource)、カーネル動的分析 (clEnqueue* コマンド フェーズ)、およびデバイス マッピングが含まれます。MultiCL 動的スケジューリング モジュールは、独立したスレッドを通じて OpenCL プログラムと同時に実行され、OpenCL 初期化フェーズのオーバーヘッドを使用して、MultiCL ランタイム カーネル分析とデバイス分析によって生じるオーバーヘッドを隠します。

図 1 MultiCL ランタイム構造図

MultiCL 動的スケジューリングには、デバイス アナライザー、カーネル アナライザー、タスク スケジューラーという 3 つの主要なランタイム モジュールが含まれています。

  1. デバイス プロファイラー。デバイスのパフォーマンス (メモリ、計算能力、I/O) を収集および分析するために使用されます。
  2. カーネル プロファイラー。さまざまなデバイスでのカーネルの実行時間を分析および予測します。
  3. タスク スケジューラは、SCHED_AUTO とマークされたコマンド キュー内のタスクをデバイスにスケジュールします。上記の 3 つのランタイム モジュールは、OpenCL 標準の MultiCL 拡張に基づいて OpenCL タスクの動的スケジューリングを実装します。デバイス アナライザーとカーネル アナライザーは、それぞれ OpenCL デバイスとカーネルを分析し、OpenCL デバイスとカーネル間の適合度を判断し、タスク スケジューラーにデータ ベースを提供します。

デバイス プロファイラは、OpenCL clGetPlatformIds コマンドの呼び出し中に実行されるデバイス プロファイラです。デバイス アナライザーは、デバイス プロファイルから OpenCL デバイスのプロファイル情報を取得します。デバイスのプロファイル情報がファイルに存在しない場合、MultiCL ランタイムはデータ帯域幅と命令スループットのベンチマークを実行し、測定されたメトリックを静的情報としてデバイス プロファイルに保存します。ベンチマークは SHOC Benchmarks NVIDIA SDK から派生しており、これらのベンチマークは MultiCL ランタイムの一部です。ベンチマークを再度実行する必要があるのは、システム構成が変更された場合 (たとえば、新しいデバイスがシステムに追加または削除された場合) のみです。

カーネル プロファイラは、パフォーマンス モデリングまたはパフォーマンス予測手法を通じてカーネルの実行時間を推定します。カーネル アナライザーによって生じる時間のオーバーヘッドを削減するために、MultiCL はデバイスごとにミニ カーネルを 1 回実行し、対応する実行時間をカーネル構成ファイルの一部として保存します。このマイクロカーネルは、マイクロ シミュレーション テクノロジによって作成され、システム内のコンピューティングに参加するすべてのデバイス上で実行されるようにスケジュールされており、個々のワークグループの作業項目を分割し、各デバイス上のマイクロカーネルの相対的なパフォーマンスを記録します。この方法では、現在のプログラムに潜在的なランタイム オーバーヘッドが生じますが、MultiCL で使用されるマイクロ カーネルのランタイム最適化後、そのランタイム オーバーヘッドは非常に小さく、場合によっては無視できることが実験で確認されています。同時に、この方法は、さまざまなデバイスでのカーネルの動作の違いをより正確に反映することもできます。マイクロカーネルの作成は、OpenCL の clCreateProgramWithSource および clBuildProgram コマンドの実行中に行われます。MultiCL ランタイムは、clCreateProgramWithSource 呼び出しをインターセプトし、各コアのミニカーネル オブジェクトを作成し、clBuildProgram 呼び出しをインターセプトして、新しいミニカーネルを使用してプログラムを別のバイナリに構築します。このアプローチでは OpenCL のビルド時間が 2 倍になりますが、著者は、これは初期セットアップのコストであり、プログラムの実際の実行時間は変わらないと考えています。

タスク スケジューラは、各 OpenCL コマンド キューを取得し、関連付けられたコマンド キューをスケジューリングのためにレディ キュー プールに追加します。MultiCL は、概要デバイス情報ファイルとカーネル構成ファイルを通じてのみタスク マッピング スキームを取得します。MultiCL ランタイムは、各キューの集約されたカーネル構成ファイルを読み取り、タスク スケジューラは、コマンド キュー カーネルの実行時間を最小限に抑え、同時実行時間を最小限にする戦略を使用して、理想的なキューとデバイスのマッピングを決定します。動的スケジューリング方式により、カーネルとデバイスの理想的なマッピングが保証されると同時に、OpenCL プラットフォーム下のデバイスの数は多くないため、スケジューリングによって発生するオーバーヘッドは無視できます。スケジューラがコマンド キューをデバイスにマップした後、キューはキュー プールから削除されます。

3 まとめ

OpenCL は、CPU、GPU、およびその他のプロセッサにわたる異種ハイブリッド プログラミングに適した、異種システムの汎用並列プログラミング用のオープン スタンダードを提案した最初の企業です。MultiCL は OpenCL 標準を拡張して、コンテキスト フル レベルおよびコマンド キューのローカル レベルで静的および動的スケジューリングを実行します。MultiCL は、OpenCL 自体の開発者によって指定された静的スケジューリング方法を維持しながら、デバイス アナライザー、カーネル アナライザー、およびタスク スケジューラーを通じて OpenCL の動的スケジューリングを完了するランタイム システムです。MultiCL ランタイムの最適化により、開発者はアプリケーション レベルのデータとタスク スケジューラに集中できます。デバイスレベルのアーキテクチャの詳細やデバイスのスケジューリングではなく、タスクの分解により、OpenCL 開発の困難さが大幅に軽減され、将来のタスク スケジューリングの研究に優れたソフトウェア サポートが提供されます。ただし、MultiCL では実行前のオーバーヘッドが発生し、プログラムの実行効率が低下すると同時に、その実行前評価スキームはカーネルの実際の動作状態を反映できず、さらなる最適化が必要です。

著者: JD Logistics Jin Zwei

出典:JD Cloud Developer Community Ziyuanqishuo Tech 転載の際は出典を明記してください

Alibaba Cloudが深刻な障害に見舞われ、全製品に影響(復旧済み) ロシアのオペレーティングシステム「Aurora OS 5.0」、新UIが Tumblrで公開 多くのインターネット企業がHongmengプログラマーを緊急採用 .NET 8が正式にGA、最新版LTS版 UNIX時間 17億時代に突入しようとしている(すでに突入) XiaomiはXiaomi Velaが完全にオープンソースであり、基盤となるカーネルは NuttX Linux上の.NET 8であることを公式に発表しました。独立したサイズは50%削減されます。FFmpeg 6.1」ヘビサイド」リリース Microsoft、新たな「Windowsアプリ」を発売
{{名前}}
{{名前}}

おすすめ

転載: my.oschina.net/u/4090830/blog/10143761