原題: なぜ SYCL: SYCL ルームの象
ジェームズ・レインダースとマイケル・ウォン著
抜粋: https://www.hpcwire.com/2022/02/03/why-sycl-elephants-in-the-sycl-room/
解説 — ヘテロジニアス コンピューティングに関する一連のゲスト投稿の 2 回目では、短期間の「退職」を経て昨年インテルに復帰した James Reinders 氏が、SYCL が C++ のヘテロジニアスな未来にどのように貢献するかについての記事をフォローアップします。彼には、現在の SYCL 委員長でもある Codeplay Software Ltd. の Michael Wong が加わります。彼らは一緒に、「SYCL ルームの象」と呼ぶべきものに対する応答を提供します。
コメント -ヘテロジニアス コンピューティングに関する一連のゲスト投稿の 2 回目では、短期間の「退職」を経て昨年インテルに復帰した James Reinders が、SYCL が C++ のヘテロジニアスの将来にどのように貢献するかについて語り続けています。彼には、現在の SYCL 委員長でもある Codeplay Software Ltd. の Michael Wong が加わりました。彼らは一緒に、SYCLで彼らが「部屋の中の象」と呼ぶものに反応しました。
完全な異種混合サポートをもたらす SYCL による C++ プログラミングのケースは、最近の記事「C++ の異種混合の未来を考える」や sycl.tech に列挙されているその他の多数のリソースなど、SYCL 仕様に近い人々によって詳しく説明されています。SYCL は、C++ に完全な異種データ並列処理のサポートを導入する Khronos 標準です。SYCL は万能薬ではありませんが、ハードウェアの多様性が爆発的に増加している中で、完全な異種プログラミングを適切に有効にするにはどうすればよいかという、より大きな問題の 1 つの側面に対する解決策です。
SYCL が完全なヘテロジニアス サポートをもたらすという C++ プログラミングの事例は、最近の記事「Considering C++'s Heterogeneous Future」や sycl.tech にリストされている他の多くのリソースなど、SYCL 仕様に詳しい人々によってよく説明されています。SYCL は、C++ での完全な異種データ並列処理のサポートを導入する Khronos 標準です。SYCL は万能薬ではありませんが、部分的な解決策です。ハードウェアの多様性が爆発的に増加していることを考えると、完全に異種混合プログラミングを完全に有効にするにはどうすればよいでしょうか?
この記事では、SYCL に関する主要な質問について、この分野で数十年にわたって取り組んできた私たちの視点に基づいて説明します。これらの重要な質問は、SYCL が自分たちにとって重要かどうかを理解しようとしているソフトウェア開発者によって尋ねられます。正直に言うと、すべての主要プロジェクトには、ある時点で「部屋の中の象」が登場します。[1] 成功したプロジェクトは、ゾウに対してオープンに取り組みます。
この記事では、数十年にわたりこの分野で働いてきた私たちの視点に基づいて、SYCL の主要な問題についての見解を示します。これらの重要な質問は、SYCL が自分たちにとって重要かどうかを知りたいソフトウェア開発者によって尋ねられます。正直に言うと、すべての主要プロジェクトには、ある時点で「部屋の中の象」が登場します。[1] 成功したプロジェクトは問題に率直に取り組みます。
象 1: GPU だけでは十分ではありませんか? 他のアクセラレータは本当に重要ですか?
象 1: GPU だけでは十分ではありませんか? 他のアクセラレータは本当に重要ですか?
どのアクセラレーターが今後も残るのか、どれが一時的な流行で終わるのかについては、当然の疑問が存在します。何十年もの間、CPU が存続する一方で、さまざまなアクセラレータが登場しては消えていきました。現在、GPU はほとんどのコンピューター システムに搭載されています。GPU がほぼ遍在していることを考えると、GPU を利用するようにアプリケーションを作成することは非常に理にかなっています。
どのアクセラレータが今後も残り、どれが流行になるかについては、当然の疑問がいくつかあります。何十年にもわたってさまざまなアクセラレータが登場しては消えていきましたが、CPU は残り続けています。現在、GPU はほとんどのコンピューター システムに搭載されています。GPU がほぼどこにでもあることを考えると、GPU を活用するアプリケーションを作成することは理にかなっています。
その結果、最初の疑問の 1 つは、本当に一般化する必要があるのか、つまり、マルチアーキテクチャおよびマルチベンダーである必要があるのかということです。
最初の疑問の 1 つは、本当に一般化が必要か、つまりマルチ アーキテクチャとマルチ ベンダーが必要かということです。
将来的には、この10年間のコンピューティングに必須の機能として「専用または半専用のハードウェアアクセラレータ」が必要になると、近藤正明教授率いる研究者を含む専門家が『次世代先端コンピューティングインフラ白書』で予想している。 」、および Hennessy & Patterson による論文「コンピュータ アーキテクチャの新しい黄金時代」。
近藤正明教授らの研究者らの専門家は、『次世代先端コンピューティングインフラ白書』の中で、今後10年間のコンピューティングの必須機能として「専用または半専用のハードウェアアクセラレータ」が必要になると予測している。」とヘネシーとパターソンの論文「コンピューター アーキテクチャの新しい黄金時代」。
専用アクセラレータについて話している限り、なぜ GPU にとどまるのでしょうか? さまざまなタイプのアクセラレータに合わせて最適化することは大きな目標ですが、さまざまなタイプのアクセラレータに異なるコードを作成することは望ましくありません。私たちは、誰もが貢献、共同作業でき、特定のベンダーに縛られず、メンバーや一般の要件に基づいて有機的に進化できる、標準化された言語から業界が恩恵を受けると信じています。
専用アクセラレータについて話しているのに、なぜ GPU にとどまるのでしょうか? さまざまな種類のアクセラレータに合わせて最適化することは素晴らしい目標ですが、異なる種類のアクセラレータに対して異なるコードを作成することは望ましくありません。私たちは、業界は、誰もが貢献し、協力し、特定のベンダーに縛られることなく、メンバーや一般の人々の要件に基づいて有機的に成長できる標準化された言語から恩恵を受けると信じています。
SYCL は、必要なときに共通のコードを使用し、必要なときに特化できるようにする興味深いアプローチを採用しています。このように、SYCL は一般にアクセラレータを採用しており、いつ共通のアーキテクチャにまたがるコードを記述するか、またコードを特殊化することが十分に有利であると思われる場合の決定は開発者に委ねられています。
SYCL は興味深いアプローチを採用しており、必要なときに汎用コードを使用し、必要なときに特化することができます。このように、SYCL はアクセラレータ全般を採用しており、開発者はアーキテクチャ間で共通のコードをいつ作成するか、また特殊なコードに十分なメリットがあると考えられる場合を決定できます。
その基礎となるプログラミング モデルである SPMD は、多くのアーキテクチャで使用できることがわかっています。SPMD は、Nvidia CUDA/OpenCL/SYCL を使用するほとんどのプログラマーが考える方法です。つまり、1 つのワークアイテムを操作する観点からコードを記述し、複数のワークアイテムがベクター ハードウェア レーンを満たすように、それがほとんどのハードウェアで同時に実行されることを期待しています。
その基礎となるプログラミング モデルである SPMD は、さまざまなアーキテクチャで動作することが証明されています。SPMD は、Nvidia CUDA/OpenCL/SYCL を使用するほとんどのプログラマーが考える方法です。つまり、1 つのワークアイテムを操作する観点からコードを記述し、それがほとんどのハードウェアで同時に実行されることを期待し、複数のワークアイテムがベクター ハードウェア レーンを満たすようにします。
SYCL は、アーキテクチャ (GPU、FPGA、ASIC など) だけでなく、ベンダー (GPU の多くの異なるソースなど) 間でも高度な移植性を提供します。
SYCL は、ベンダー (さまざまな GPU ソースなど) やアーキテクチャ (GPU、FPGA、ASIC など) 間での高度な移植性を提供します。
象 2: Nvidia CUDA を使用しないのはなぜですか?
象 2: Nvidia CUDA を使用しないのはなぜですか?
複数の GPU ベンダーによる競争のおかげで、活気に満ちた GPU エコシステムが出現しています。これは、一般的にアクセラレータをめぐる競争がますます激化する傾向の一部です。Nvidia GPU を利用する CUDA アプリケーションのインストール ベースは、Nvidia だけでなくすべてのベンダーにサービスを提供するために作成されたオープン、マルチベンダー、マルチアーキテクチャのソフトウェア アプローチに時間の経過とともに適応できる態勢が整っています。
複数の GPU ベンダーによる競争により、活気のある GPU エコシステムが出現しています。これは、アクセラレーターの競争が激化する傾向の一部です。Nvidia GPU を使用する CUDA アプリケーションのインストール ベースは、Nvidia だけでなくすべてのベンダーにサービスを提供するように設計されたオープン、マルチベンダー、マルチ アーキテクチャのソフトウェア アプローチに時間の経過とともに適応できるようになります。
CUDA は、その価値提案とエコシステムにおける Nvidia GPU の強みを考慮して根強い支持を得ていますが、CUDA の使用によって生じるロックインに関する懸念が高まっています。このような懸念は、次の要因によって強調される独自の焦点から生じています。
CUDA は、その価値提案とエコシステムにおける Nvidia GPU の強みにより多くの支持を得ていますが、CUDA の使用によって引き起こされるロックインについての懸念が高まっています。これらの懸念は、次のような独自の懸念から生じています。
-
CUDA の定義、その実装と進化は Nvidia によって管理され、特に Nvidia GPU 製品設計に役立つように進化します。CUDA の新機能の詳細は、NVIDIA がそれらをサポートするハードウェアとソフトウェアの両方を用意するまで、一般には公開されません。以下で詳しく説明しますが、この制御は他のベンダーによるイノベーションを抑制します。
-
Nvidia からの CUDA ツールとライブラリのライセンスには、これらを「Nvidia GPU を備えたシステムでのみ使用するアプリケーションの開発」に使用する必要があると明記されています。Nvidia の「オープンソース」にも、同様に重要な部分を制限するライセンス言語が含まれています。
1. CUDA の定義、実装、開発は Nvidia によって管理され、Nvidia GPU 製品設計に役立つように特別に開発されています。CUDA の新機能の詳細は、通常、NVIDIA がそれらをサポートするハードウェアとソフトウェアを用意するまで公開されません。以下でさらに詳しく説明しますが、この制御は他のサプライヤーによるイノベーションを阻害します。
2. Nvidia の CUDA ツールとライブラリのライセンスには、「Nvidia GPU を備えたシステムでのみ使用するアプリケーションを開発するために」使用する必要があると具体的に記載されています。 Nvidia の「オープンソース」にも、同様に主要な部分を制限するライセンス言語が含まれています。
Nvidia CUDA は、Nvidia GPU を使用してアクセラレーション コンピューティングを大衆にもたらした功績を主張できます。アクセラレータ市場での競争の激化により、CUDA はますますオープンで透明性の高い世界で壁に囲まれた庭園になっているように見えるかもしれません。オープンで、 CUDA に代わるマルチベンダー、マルチアーキテクチャがなくなるわけではありません。
Nvidia CUDA は、Nvidia GPU を使用して高速コンピューティングを大衆に提供することで有名です。アクセラレータ市場で競争が激化する中、CUDA はますますオープンで透明性の高い世界の中で壁に囲まれた庭園になっているようです。CUDA に代わる、オープン、マルチベンダー、マルチ アーキテクチャへの要望は消えることはありません。
象 3: AMD HIP を使用しないのはなぜですか?
象 3: AMD HIP を使用しないのはなぜですか?
AMD Heterogeneous-Computing Interface for Portability (HIP) は C++ 言語です。AMD ツールには、CUDA コードを HIP に変換するのに役立つ「HIPify ツール」が含まれています。AMD は、「HIP コードは、元の CUDA コードと比較してパフォーマンスを損なうことなく、AMD ハードウェア (HCC コンパイラ経由) または Nvidia ハードウェア (NVCC コンパイラ経由) で実行できます。」と述べています。
AMD ヘテロジニアス コンピューティング ポータブル インターフェイス (HIP) は C++ 言語です。AMD ツールには、CUDA コードを HIP に変換するのに役立つ「HIPify ツール」が含まれています。AMD によると、「HIP コードは、元の CUDA コードと比較してパフォーマンスを犠牲にすることなく、AMD ハードウェア (HCC コンパイラ経由) または Nvidia ハードウェア (NVCC コンパイラ経由) で実行できます。」
HIP は「CUDA に従う」戦略です。つまり、Nvidia が CUDA プラットフォームのアップデートをリリースした後、AMD ができるだけ早く HIP のアップデートを開発します。HIP を支持する議論は、AMD GPU 用の大規模な CUDA コードベースの再利用の長所に基づいています。残念ながら、CUDA の不透明性を考慮すると、誰も CUDA を厳密に、タイムリーに、または正確に追跡することはできません。これにより、CUDA 開発者に AMD GPU 用の #ifdef を使用してコードを変更することを強いることなしに、AMD が独自の AMD ハードウェア革新を公開する機会が得られません。
HIP は「CUDA に従う」戦略であり、AMD は Nvidia が CUDA プラットフォームのアップデートをリリースした後、できるだけ早く HIP アップデートを開発します。HIP を支持する議論は、大規模な CUDA コード ベースを再利用する AMD GPU の利点に基づいています。残念ながら、 その不透明な性質を考えると、誰も CUDA を詳細に、タイムリーに、または正確に追跡することはできません。CUDA 開発者に AMD GPU 用の #ifdef を使用してコードを変更することを強制しなければ、AMD は独自の AMD ハードウェア革新を紹介する機会がありません。
AMD は、Nvidia GPU の代替として AMD GPU を求めるユーザー向けに HIP で価値を生み出してきましたが、さらに多くのことを求めるのは難しくありません。CUDA の機能革新とパフォーマンスに対応できるソリューションがあることを想像してみてください。
私たちは、イノベーションは壁に囲まれた庭園の影ではなく、オープンフィールドで最も繁栄すると信じています。
[編集者注: hipSYCL と呼ばれる SYCL 実装があり、HIP の上に位置し、ROCm および Nvidia GPU を実行する AMD GPU をターゲットとしています。
AMD は、Nvidia GPU の代替として AMD GPU を探しているユーザー向けに HIP を通じて価値を生み出してきましたが、さらに多くのものを求めるのは難しくありません。CUDA の機能革新とパフォーマンスに遅れを取らないソリューションがあることを想像してみてください。私たちは、イノベーションは壁に囲まれた庭園の影ではなく、オープンフィールドで繁栄すると信じています。
[編集者注: hipSYCL と呼ばれる SYCL 実装があり、HIP の上に位置し、ROCm および Nvidia GPU を実行する AMD GPU をターゲットとしています。]
象 4: OpenCL を使用しないのはなぜですか?
象 4: OpenCL を使用しないのはなぜですか?
OpenCL はオープン マルチベンダーの代替手段を提供しますが、SYCL や CUDA が提供するものよりもソフトウェア スタックの下位層にあります。SYCL は、異種並列アーキテクチャ用の標準 C++ インターフェイスを提供することで、OpenCL のオープン、マルチベンダー、マルチアーキテクチャ アプローチの利点をもたらしたいという要望から生まれました。SYCL 実装では、実装に OpenCL を利用することがよくありますが、SYCL2020 の時点では内部で他のバックエンドを使用する柔軟性もあります。SYCL は、C++ 抽象化を通じて生産性を向上させ、OpenCL の約束を実現します。
OpenCL は、オープンなマルチベンダーの代替手段を提供しますが、SYCL や CUDA が提供するものよりも低いソフトウェア スタック レベルです。SYCL は、異種並列アーキテクチャに標準 C++ インターフェイスを提供することにより、OpenCL のオープン、マルチベンダー、マルチアーキテクチャのアプローチを活用するために生まれました。SYCL 実装は通常、OpenCL を使用して実装されますが、SYCL2020 以降は、バックエンドで他のバックエンドを使用する柔軟性も備えています。SYCL は、C++ 抽象化を通じて、より生産的な形式で OpenCL の約束を実現します。
象 5: C++ を使えばいいんじゃないの?
象 5: C++ を使えばいいんじゃないの?
まず、異種マシンをプログラムしたい、移植性を重視し、移植性のためにパフォーマンスにペナルティを払いたくない、という仮定から始めましょう。
まず、異種マシンをプログラムしたい、移植性を重視し、移植性のためにパフォーマンスを犠牲にしたくない、と仮定しましょう。
「はい」と答えるかもしれません 。SYCL もサポートしている場合は C++ で十分です。結局のところ、C++ は SYCL などのテンプレート ライブラリによって拡張されるように構築されています。SYCL は新しいキーワードを追加しませんが、クロスコンパイル、ファット バイナリ、およびリモート メモリを支援する SYCL 対応 C++ コンパイラの恩恵を受けます。これらは単に、C++ コンパイラーが歴史的に容易にしなかったことです。
おそらく「はい」と答えるでしょう。SYCL もサポートしている場合は、C++ で十分です。結局のところ、C++ は SYCL などのテンプレート ライブラリを通じて拡張できるように構築されています。SYCL は新しいキーワードを追加しませんが、クロスコンパイル、ファット バイナリ、およびリモート メモリを支援する SYCL 対応 C++ コンパイラの恩恵を受けます。これらは、歴史的に C++ コンパイラーが実行するのが容易ではなかったことです。
SYCL は、標準 C++ 内で、ISO C++ 上に構築された完全なヘテロジニアス コンピューティングのプログラミングに対応するソリューションも提供しています。これには、デバイスの列挙 (情報)、作業の定義 (カーネル)、デバイス間での作業の送信と調整 (キュー)、およびリモート メモリの管理が含まれます。
現在、SYCL は、ISO C++ 上に構築された完全なヘテロジニアス コンピューティングのプログラミング問題を解決する標準 C++ のソリューションも提供しています。これには、デバイスの列挙 (情報)、作業の定義 (カーネル)、デバイス間での作業の送信と調整 (キュー)、およびリモート メモリの管理が含まれます。
それは私たちに「いいえ」をもたらします。 – C++ 標準では、互いに素な (非コヒーレントな) メモリを備えた異種システムのサポートは定義されていません。いつかそれが追加されるだろうと考える人もおり、その方向に進む努力は行われていますが、関係者ですら、現在の方向性には少なくとも 10 年かかり、C++ が数百万行との下位互換性を維持する必要があるため限界があると考えています。既存のコードの。実際、私たちのうちの 1 人 (MW) は、C++ にその方向を促す論文を書きました。WG21 (ISO C++) からの対応は、下位互換性への懸念から当然のことですが、メモリとアドレス指定モデルに根本的な外科的変更を加えるのではなく、並列アルゴリズムとエグゼキュータから開始し、前方進行保証を追加することでした。したがって、異種マシンをプログラミングしている場合、「C++ で十分だ」と主張するのは十分ではないでしょう。」 その方向に進もうとしている企業もいますが、それが競争業界の素晴らしさであり、何が市場と消費者の利益になるのかがわかります。ただし、現在すぐに機能するものは、「C++ プラス SYCL」、「C++ プラス CUDA」、または「C++ プラス OpenCL」です。
これにより、「いいえ」という結論が得られます。C++ 標準では、互いに素な (非コヒーレントな) メモリを備えた異種システムのサポートは定義されていません。これはいつか追加されるだろうと考え、その方向に取り組んでいる人もいますが、関係者ですら、現在の方向性は少なくとも 10 年は先であり、C++ が数百万行との下位互換性を維持する必要があることが妨げになっていると考えています。性的な制限。既存のコード。実際、私たちの一人 (MW) は、C++ がこの方向に進むよう促す論文を書きました。下位互換性の理由から、WG21 (ISO C++) は、メモリとアドレス指定モデルに根本的な外科的変更を加えるのではなく、並列アルゴリズムとエグゼキュータから始めて、前進の進行保証を追加することで対応しました。したがって、異種マシンでプログラミングしている場合、「C++ で十分」と主張するだけでは十分ではない可能性があります。この方向に進もうとしている人々がいます。それが競争業界の素晴らしいところです。何が市場と消費者の最大の利益になるのかがわかります。ただし、現在すぐに機能するのは、「C++ プラス SYCL」、「C++ プラス CUDA」、または「C++ プラス OpenCL」です。
C++ コンパイラとランタイムに SYCL サポートを追加する目的は、SYCL なしでは現在提供されていない完全な異種サポートを C++ がサポートできるようにする機能を追加することです。ISO 標準は既存の知識のベスト プラクティスを標準化する傾向があるため、これは C++ が将来的に異種混合をどのようにサポートできるかを示す方法でもあります。以下にその一例を示します。
C++ コンパイラとランタイムに SYCL サポートを追加する目的は、SYCL なしでは C++ が現在提供できない完全な異種サポートを C++ がサポートできるようにする機能を追加することです。ISO 標準は既存の知識に基づいてベスト プラクティスを標準化する傾向があるため、これは C++ が将来的に異種混合をどのようにサポートできるかを示す方法でもあります。以下にその例を示します。
象 6: SYCL キューを ISO C++ に組み込むことはできますか?
象 6: SYCL キューを ISO C++ に入れることはできますか?
キューは、SYCL が異種デバイスに作業を割り当てる方法であり、複雑なメモリ システム (必ずしも統合されて一貫しているわけではありません) 内でのデータの受け渡しも含まれます。
キューは、必ずしも統一されていて一貫性があるわけではない複雑なメモリ システム内でデータを渡すなど、作業を異種デバイスに分散する SYCL の方法です。
長期的にはキュー クラスが C++ に属するかどうかを推測するのは簡単ですが、そのような推測は時期尚早です。
長期的には、キュー クラスが C++ に属するかどうかを推測するのは簡単ですが、そのような推測は時期尚早です。
C++23 の提案には、p2300 の「std::execution」など、特定のデバイスに実行を指示するためのさまざまな構造が含まれています。C++23 は今後も統一されたグローバル メモリ アドレス空間に依存し、素のリモート メモリ (複雑なメモリ システム) をサポートしないことがわかっています。
C++23 の提案には、p2300 の「std::execution」を含む、特定のデバイスへの直接実行のためのさまざまな構造が含まれています。C++23 は引き続き統一されたグローバル メモリ アドレス空間に依存し、素のリモート メモリ (複雑なメモリ システム) をサポートしないことがわかっています。
構文に囚われやすいです。最終的に、C++ が完全な異種混合サポートを含むように拡張されると、SYCL キューに具体化された概念が必要になります。それまでは、SYCL がこの空白を埋めます。並列ディレクティブやメッセージ パッシングなどの一部の重要な機能は、独立した標準のままです (OpenMP および MPI)。C++ が完全な異種混合サポートを含めるように成長しない可能性もありますが、C++ は最終的にそのようなサポートを段階的に追加すると考えています。
文法で行き詰まってしまうのは簡単です。最終的に、C++ が完全な異種混合サポートを含むように拡張される場合、SYCL キューに具体化された概念が必要になります。それまでは、SYCL がそのギャップを埋めてきました。並列命令やメッセージ パッシングなどの一部の重要な機能は、別個の標準 (OpenMP および MPI) のままです。C++ は完全な異種サポートを含めるように進化することはないかもしれませんが、C++ は時間の経過とともに最終的にそのようなサポートを追加すると信じています。
C++ は、実証されていない新しい機能を発明するのではなく、確立されたベスト プラクティスを標準化することを目的としているため、SYCL は、意図的にゆっくりと進む C++ 標準化プロセスに「確立されたベスト プラクティス」を送り込む多くのフィーダーの 1 つとして重要な足掛かりとなります。
C++ の目標は、実証されていない新しい機能を発明するのではなく、確立されたベスト プラクティスを標準化することであるため、SYCL は、意図的にゆっくりとした C++ 標準化プロセスへの「確立されたベスト プラクティス」としての重要な足掛かりとなります。
C++23 が落ち着き、C++26 が検討されるにつれて、異機種混合コンピューティングにおける C++ の将来が構文も含めて具体化し始めますが、おそらく完全なソリューションはあと 5 ～ 10 年は出現しないでしょう。
C++23 が安定し、C++26 が検討されるにつれて、C++ でのヘテロジニアス コンピューティングの将来が構文も含めて具体化し始めますが、完全なソリューションはさらに 5 ～ 10 年は出現しない可能性があります。
SYCL は、標準 C++ 内で完全なヘテロジニアス コンピューティングのプログラミングに対応するソリューションを現在提供しています。これには、デバイスの列挙 (情報)、作業の定義 (カーネル)、デバイスへの作業の送信 (キュー)、およびリモート メモリの管理が含まれます。
SYCL は、完全な異種コンピューティングのプログラミング問題に対する標準 C++ のソリューションを提供します。これには、デバイスの列挙 (情報)、作業の定義 (カーネル)、デバイスへの作業の送信 (キュー)、およびリモート メモリの管理が含まれます。
象 7: SYCL の背後にいるのは誰ですか? それは本当に本当の意味でオープンなのでしょうか？
象 7: SYCL の背後にいるのは誰ですか? 本当に本当の意味でオープンなのか？
私たちは、オープンな国際標準とオープンソース ソフトウェア (OSS) プロジェクトがすべての人にとって有益であると信じています。Intel と Codeplay の関係者が関与すると、WiFi、USB、PCIe から OpenMP、MPI、Fortran、C、C++、OpenCL、SYCL に至るまで、そのような標準や OSS の開発と推進に熱心に取り組んでいることがわかりました。
私たちは、オープンな国際標準とオープンソース ソフトウェア (OSS) プロジェクトがすべての人にとって有益であると信じています。Intel と Codeplay の関係者が関与すると、WiFi、USB、PCIe から OpenMP、MPI、Fortran、C、C++、OpenCL、SYCL に至るまで、そのような標準や OSS の開発と推進を支援する彼らの取り組みが見られます。
Apple は、かなり低レベルの C インターフェイスのセットとして始まった OpenCL の背後にある最初の勢力でした。SYCL はもともと、特に C++ を使用した高レベルのインターフェイスを検討するための OpenCL 内の取り組みから生まれました。数年にわたる非常にオープンな議論を経て、SYCL が誕生しました。Codeplay は当初から SYCL に貢献してきました。Intel は、FPGA 市場に参入し、コンピューティング用の GPU を組み込んだ Intel Xe アーキテクチャを発表した後、SYCL への関心が高まりました。インテルは、SYCL 委員会の積極的なメンバーであり、SYCL をサポートする実装に積極的に貢献していることを誇りに思っています。SYCL はコミュニティの取り組みであり、この記事の著者 (Intel と Codeplay) の両方の家庭が、他の多くの人々とともに熱心な参加者です。
Apple は、かなり低レベルの C インターフェイスのセットとして始まったOpenCL の背後にある最初の勢力でした。SYCL は、特に C++ を使用した高レベルのインターフェイスを検討する OpenCL 内の取り組みから生まれました。何年もの公開討論を経て、SYCL が誕生しました。コードプレイは当初から SYCL で重要な役割を果たしてきました。Intel は FPGA 市場に参入し、Intel Xe アーキテクチャにコンピューティング用の GPU が含まれていることを発表してから、SYCL への関心が高まっています。インテルは、SYCL 委員会の積極的なメンバーであることを誇りに思っており、SYCL の実装のサポートに積極的に貢献しています。SYCL はコミュニティの取り組みであり、この記事の著者のうち 2 名 (Intel と Codeplay) および他の多くの著者が熱心な参加者です。
象 8: 象の群れが見えます – なぜ SYCL を信じなければならないのですか?
象 8: 象の群れを見ました - なぜ SYCL を信頼する必要があるのですか?
複数の異種マシン向けにアプリケーションをプログラムする必要がまだない場合は、なぜ私たちが SYCL の見通しにこれほど興奮しているのかを理解するのが難しいかもしれません。必要性を問うのは非常に論理的です。
複数の異種マシン用のアプリケーションを作成する必要がなかった場合は、おそらく、なぜ私たちが SYCL の可能性についてこれほど興奮しているのか、実際には理解できていないでしょう。この必要性に疑問を呈するのは非常に論理的です。
異種混合プログラミングには多くの使用例があります。CPPCON 2021 のチュートリアルでは、大企業、中小企業、国立研究所のプログラマーに、高スループットのワークロードを専用のアクセラレータにオフロードする方法を教えました。
異種混合プログラミングには多くの使用例があります。CPPCON 2021 チュートリアルでは、大企業、中小企業、国立研究所のプログラマーに、高スループットのワークロードを専用のアクセラレータにオフロードする方法を教えます。
このような多くの経験に基づいて、異種プラットフォーム向けの C++ プログラミングの必要性により、SYCL への関心が急速に高まり続けると確信できる十分な理由があります。
多くの同様の経験に基づいて、異種プラットフォームでの C++ プログラミングの需要により、SYCL への関心が急速に高まり続けると信じる十分な理由があります。
ハードウェアの多様性の力を信じており、差し迫ったアーキテクチャの多様性の爆発を活用したい場合は、SYCL を検討する価値があります。オープン、マルチベンダー、マルチアーキテクチャの機能だけでなく、C++ プログラマーにとって重要なものでもあります (「C++ の異種混合の未来を考える」で詳しく説明されています)。
ハードウェアの多様性の力を信じており、今後爆発的に増加するアーキテクチャの多様性を活用したい場合は、SYCL を検討する価値があります。これは、オープン、マルチベンダー、マルチアーキテクチャのゲームであるだけでなく、C++ プログラマにとっても重要です (詳細については、「C++ の異種混合の将来を考える」を参照してください)。
大量市場を可能にするためには、オープンな業界標準が不可欠です
オープンな業界標準は、大量市場を可能にするために不可欠です
新しいテクノロジーは独自の開発として開始されることが多く、ニッチなアプリケーションや市場を可能にするのに十分な場合があります。しかし、これらのニッチなアプリケーションがテクノロジー エコシステムに成長するにつれて、広範な採用を可能にするための競争と業界の標準化の必要性も高まります。アクセラレーテッド コンピューティングは、長年にわたりニッチな機能にすぎませんでしたが、確実に「定着する」地位を確立して登場しました。これには複数の要因が寄与しており、それらすべてがなくなるわけではありません (電力の壁、IPC の壁、メモリの壁)。
新しいテクノロジーは多くの場合、独自の開発から始まり、ニッチなアプリケーションや市場を可能にするのに十分な場合があります。しかし、これらのニッチなアプリケーションがテクノロジー エコシステムに成長するにつれて、広く普及させるために競争と業界標準化の必要性が高まります。アクセラレーテッド コンピューティングは長年にわたりニッチな機能でしたが、確実に「長期的な存在」として浮上してきました。これには多くの要因があり、それらすべてが消えるわけではありません (電源の壁、IPC の壁、メモリの壁)。
SYCL および oneAPI などの関連する取り組みは、歴史的に独自のアクセラレーション コンピューティングの世界にオープンな業界標準を導入するために導入されました。
SYCL および oneAPI などの関連する取り組みは、歴史的に独自のアクセラレーション コンピューティングの世界にオープンな業界標準を導入するために開始されました。
最大の疑問は、何人のインフルエンサーが標準への移行を熱心に推進しているのに対し、何人のインフルエンサーが専有的利益に縛られているのかということだ。
大きな疑問は、何人のインフルエンサーが標準を前進させようと熱意を持っているのか、そして何人のインフルエンサーが専有的利益によって足を引っ張られているのかということだ。
新しいコンピュータ アーキテクチャのカンブリア紀の爆発が展開するにつれて、オープン、マルチベンダー、マルチアーキテクチャ標準の必要性はますます強まっています。
新しいコンピュータ アーキテクチャの爆発的な発展に伴い、オープン、マルチベンダー、マルチ アーキテクチャの標準に対するニーズはますます強まるでしょう。
SYCL は、標準およびそれを実装するオープン ソース プロジェクトに対するすべてのユーザーからのフィードバックと貢献を募るオープン スタンダードです。関係者全員の共通の目標は、コンピューター アーキテクチャのこのエキサイティングな新たな黄金時代において、すべてのアクセラレーターの高性能への道を明確に確保することです。
SYCL は、標準およびそれを実装するオープン ソース プロジェクトに対してフィードバックや貢献を提供することを誰にでも勧めるオープン スタンダードです。すべての参加者の共通の目標は、コンピュータ アーキテクチャのこのエキサイティングな新しい黄金時代において、すべてのアクセラレータが確実に高いパフォーマンスを達成できるようにすることです。
著者について
James Reinders 氏は、 完全なヘテロジニアス コンピューティングへの進化のメリットは、オープン、マルチベンダー、マルチアーキテクチャのアプローチによって最もよく実現されると考えています。Reinders 氏は 1 年前にインテルに再入社しました。その理由は、インテルがこの開かれた未来の実現に有意義に貢献できると信じているからです。Reinders は、並列プログラミングに関連する 10 冊の技術本の著者 (または共著者および/または編集者) です。彼の最新の本は SYCL に関するものです (ここから無料でダウンロードできます)。
マイケル・ウォン Codeplay Software の Distinguished Engineer です。彼は現在、ISOCPP Foundation の取締役兼副社長であり、25 年以上の経験を持つ C++ 標準委員会の上級メンバーです。彼は C++ Directions グループのメンバーです。彼は、WG21 SG19 機械学習および SG14 ゲーム開発/低レイテンシ/財務 C++ グループの議長を務めており、一般化された属性、ユーザー定義リテラル、継承コンストラクター、弱順序メモリ モデルを含む多数の C++/OpenMP/トランザクション メモリ機能の共著者です。 、および明示的な変換演算子。彼は多数の研究論文を発表しており、C++11 に関する本の著者でもあります。彼は数多くのカンファレンスで招待講演や基調講演を行ってきました。彼は現在、SG1 Concurrency TS および SG5 Transactional Memory TS の編集者です。彼は、SYCL 標準およびカナダ標準化協議会のすべてのプログラミング言語の議長でもあります。以前は、OpenMP の CEO として OpenMP の Accelerator サポートに携わり、IBM の XL C++ コンパイラー チームを率いた後、IBM のコンパイラーの Clang/LLVM への移行を担当する技術戦略アーキテクトを務めました。
[1] 部屋の中の象は、明らかな重要な質問として定義できますが、少なくとも一部の人を不快にさせるため、誰も言及しません。
皆さんもこれを見たことがあるでしょう、少しお話しませんか!
-
(国内) チップ企業の観点からは、ユーザーが複数の異種マシンに直面するアプリケーションを作成する必要がある可能性があるとは考えたくありません。しかし、これこそが市場が必要としているものであり、この種の革新的なアイデアはサードパーティからのみ生まれます。
-
今年、Codeplay が Intel に完全に買収されたことは知っています。しかし、そのような企業が中国で生き残れる余地はあるのだろうか？Pengfeng Technology や First Class Technology のような基本的なソフトウェアの研究開発に取り組む企業は近年中国では珍しく、もし生き残ることができないとしたら、中国のコンピューティング産業にどんな希望があるでしょうか? また、投資家の皆様には、このような小さくて美しいソフトウェア会社を歪めず、皆が一緒に成功できるよう支援していただきたいと願っています。