Rustのエコシステムは、 CubeCL というマルチプラットフォームの計算言語拡張により、高性能コンピューティングの分野での能力を拡大し続けています。これにより開発者はRustで直接GPUコードを記述することが可能になります。このプロジェクトは大きな関心を集めていますが、コミュニティでの議論からは、その可能性に対する熱意と同時に、現在のドキュメントと機能の説明に関する懸念も明らかになっています。
最小限のドキュメントの背後に隠された高度な機能
CubeCL の印象的な機能にもかかわらず、多くのコミュニティメンバーはプロジェクトの README がその最も強力な機能を十分に紹介していないと指摘しています。現在の例は主に単純な要素ごとの操作に焦点を当てており、高度なGPUコンピューティングタスクに対するライブラリの可能性を十分に示していません。
「私たちはワープ操作、 Cuda 用のバリア、ほとんどのバックエンド用のアトミック操作、さらにテンソルコア命令もサポートしています。ただ、 README にはあまり詳しく記載されていないだけです！」
プロジェクトの主要な著者の一人がこの制限を認め、 CubeCL が実際にはワープ操作（ CubeCL ではPlane Operationsと呼ばれる）、バリア、アトミック操作、さらにはテンソルコア命令などの高度なGPUプログラミング技術をサポートしていることを確認しました。チームは CUDA 用の TMA（テンソルメモリアクセラレータ）命令も実装していますが、これらの高度な機能はドキュメントで目立つように紹介されていません。
より複雑な例を求めるコミュニティの要望
複数の開発者が、特にAIワークロードで一般的に必要とされる混合精度を用いた行列乗算操作など、より複雑な例を示すことでプロジェクトが恩恵を受けるだろうと提案しました。あるコメント投稿者は、現在の要素ごとの例を、 CubeCL のAIアプリケーションにおける有用性をより良く示すための「ひねりを加えた GEMM」のデモに置き換えることを特に推奨しました。
CubeCL チームはこれらの提案に前向きに対応し、ある貢献者は FP8 や FP4 などの新しいデータ型のサポートが次のプロジェクトとして計画されていると述べました。ただし、現在はハードウェアの制限がボトルネックとなっており、これらの新しい型をテストするために必要な機器にアクセスできる貢献者が1人しかいないと指摘しました。
GPUプログラミングエコシステムにおける位置づけ
コミュニティの議論では、 CubeCL と他の GPU プログラミングソリューションとの比較も取り上げられました。複数のコメント投稿者が Halide 、 OpenCL 、 SYCL との類似点を指摘し、特に CubeCL の comptime 機能がこれらの代替手段とどのように差別化されているかに関心を示しました。
comptime システムにより、開発者はカーネル内で任意のコードをコンパイル時に実行できるようになり、従来のジェネリクスよりも柔軟性が高まります。これにより、異なるハードウェアターゲットに最適なアルゴリズムを選択するためのコンパイル時の設定に基づく自然な分岐が可能になります。
一部のユーザーは、 WGPU 、 CUDA 、 ROCm/HIP と並んで OpenCL がバックエンドとして含まれていない理由を疑問視しました。 CubeCL の貢献者は、 SPIR-V コンパイラが OpenCL と Vulkan の両方をターゲットにするインフラを持っているものの、 OpenCL ランタイムの実装には追加の作業が必要であると説明しました。また、より直接的な実装と比較した場合の CPU 上での OpenCL のパフォーマンス特性を理解することにも関心を示しました。
CubeCL 対応ランタイム:
- WGPU（クロスプラットフォーム：Vulkan、Metal、DirectX、WebGPU）
- CUDA（NVIDIA GPU向け）
- ROCm/HIP（AMD GPU向け）- 開発進行中
- 計画中：CraneliftによるSIMD命令を備えたJIT CPUランタイム
主な機能:
- 自動ベクトル化
- Comptime（コンパイル時最適化）
- 自動チューニング
- ワープ操作、バリア、アトミック操作、テンソルコアのサポート
- テンソルコアサポート付き行列乗算
Burn フレームワークとの関連性
コメントから浮かび上がった重要な背景は、 CubeCL と同じチームによって開発された深層学習フレームワーク Burn との関係です。 CubeCL は Burn の計算バックエンドとして機能し、テンソル操作を処理する一方、 Burn は自動微分、操作融合、動的計算グラフなどの高レベルの機械学習機能を管理します。
CubeCL の必要性は具体的に Burn の要件から生じました：完全な機能を備えたプログラミング言語で GPU アルゴリズムを記述する能力、操作融合のためのランタイムコンパイルを可能にすること、そしてクロスプラットフォームの互換性と最適なパフォーマンスを維持することです。開発者によれば、 Rust のエコシステムでこれらの要件をすべて満たす既存のツールは存在しませんでした。
CubeCL と Burn の関係は、パフォーマンスとクロスプラットフォーム互換性への焦点を含め、ライブラリの背後にある多くの設計決定を説明しています。また、 CubeCL を成長中の Rust ベースの機械学習エコシステムにおける重要なコンポーネントとして位置づけています。
プロジェクトが成熟するにつれて、コミュニティは CubeCL の完全な機能をより良く示す、より包括的なドキュメントと例を求めているようです。新しいデータ型のサポート計画と継続的な開発により、 CubeCL は特に機械学習アプリケーションにおいて、 Rust の GPU コンピューティングの重要なギャップを埋めるポジションにあるようです。
参照: cubecl/cubecl