この記事は、The Parallel Universe Magazine 53 号に掲載されている「Cultivate Parallel Standards: Diversity, Alignment, and Cross-Pollination」の日本語参考訳です。原文は更新される可能性があります。原文と翻訳文の内容が異なる場合は原文を優先してください。
oneAPI は、言語 (Khronos Group の SYCL*)、標準化されたライブラリー・インターフェイス (ニューラル・ネットワーク、データ・アナリティクス、その他)、およびハードウェアに近いプログラミング・インターフェイス (レベルゼロ) を含むアクセラレーター・プログラミングのオープン仕様 (oneapi.io (英語) を参照) です。oneAPI は、ハードウェアとベンダーに依存しないように設計されており、複数のベンダーの CPU、GPU、FPGA、その他のアクセラレーターで動作することが実証されています。oneAPI は、プログラミングに標準ベースのアプローチを提供し、開発者がハードウェアとソフトウェア環境間の移植性を犠牲にすることなく高いパフォーマンスを実現できるようにします。
ソフトウェア・スタックのさまざまなレベルにわたる複数の相互運用可能な標準のコレクションが oneAPI を可能にしています。その一部 (レベルゼロや SYCL* の拡張など) は oneAPI 仕様で採用されており、SYCL* や SPIR-V* などの業界標準は、oneAPI を使用した移植可能なプログラミングの基盤を提供します。さらに、OpenMP*、ISO C++、ISO Fortran などは、oneAPI でアクセラレーター・プログラミングの代替構文を記述するのに使用されます。
現在では、1 人の開発者が 1 つの言語を 1 つの抽象化レベルで使用して大規模なアプリケーションを作成することはまずないため、これらの標準間の相互運用性は非常に重要です。ほかの開発者が作成したライブラリーを呼び出して、さまざまな手法を組み合わせて使用する方がはるかに一般的です (例えば、SYCL* で作成された最適化ライブラリーを使用して Fortran や OpenMP* でアプリケーションを作成する、など)。異なる標準が新しい問題に対して独自のソリューションを提供することは珍しいことではないため、相互運用性を維持するには継続的な努力が必要です。標準が異なると、対象とする抽象化のレベルや推奨するコーディング・スタイルも異なることがあるため、新しい機能と既存の機能や確立された規約との関係を常に考慮する必要があります。しかし、標準は、互いに学習し合って、用語などを調整し、必要に応じて機能を互いに追加することがあります。
SYCL*、C++、OpenCL* の過去 10 年間を振り返ると、この調整と相互作用のプロセスが実際に作用していることが分かります (図 1)。例えば、OpenCL* 2.0 は C++11 のメモリーモデルの概念と用語を採用し、スコープと複数のアドレス空間の概念を拡張しました。その後、グループやグループ関数などの OpenCL* 2.0 の機能と C++17 の並列アルゴリズムを組み合わせた SYCL* 2020 のグループ・アルゴリズム・ライブラリーが作成され、開発者は使い慣れた C++ 構文を使用して、ハードウェア階層の複数のレベルでベンダーに最適化された操作にアクセスできるようになりました。
これは現在進行中のプロセスであり、IWOCL 2023 で発表した「SYCL* と ISO C++ の並列処理の調整に向けて」 (英語) では、SYCL* のワークアイテムや C++17 のスレッド実行などの概念の間のギャップを埋めるように設計された、SYCL* に対するいくつかの新しい調整を提案しました。これは、特定の C++17 実行ポリシーが SYCL* デバイスで正しく動作できるようにするために必要なステップであり、これらの調整により、SYCL* で使用する C++17 並列アルゴリズムの動作の推測が容易になります。
