「RustコードのSIMD高速化のための9つのルール（パート2）」

100万件の入力では、すべてのSIMDアルゴリズムがほぼ同じ結果となっています。Short1アルゴリズムは、短い入力の場合に他のアルゴリズムよりも優れているようです。

また、短い方が長いよりも高速なようです。これはキャッシュの結果か、ベンチマークで非アラインデータを処理した結果かもしれません。

ベンチマークの結論

これらのベンチマークに基づいて、Short1アルゴリズムを使用します。現時点では、LANESを32または64に設定しますが、次のルールでは少し複雑な状況について説明します。最後に、ユーザーにはSIMD拡張レベルを少なくともavx2に設定するようにアドバイスします。

ルール8：最良のSIMDアルゴリズムをas_simdを使用してプロジェクトに統合し、i128/u128用の特別なコード、さらにコンテキスト内のベンチマーキングを追加します。

as_simd

SIMDサポートを追加する前のRangeSetBlazeのメインコンストラクタはfrom_iterでした：

let a = RangeSetBlaze::from_iter([1, 2, 3]);

しかしながら、SIMD操作はイテレータよりも配列でより良く動作します。さらに、配列からRangeSetBlazeを構築することはしばしば自然なプロセスであるため、新しいfrom_sliceコンストラクタを追加しました：

#[inline]    pub fn from_slice(slice: impl AsRef<[T]>) -> Self {        T::from_slice(slice)    }

新しいコンストラクタは、各整数のfrom_sliceメソッドに直接呼び出しを行います。整数型では、ただしi128/u128を除くすべてに対して、次のようになります：

let (prefix, middle, suffix) = slice.as_simd();

Rustの夜間ビルドでのas_simdメソッドは、スライスを安全かつ迅速に以下のものに変換します：

1. アンアライントprefix — これは以前と同様にfrom_iterで処理します。
2. middleは、Simd構造体のチャンクからなるアライメントされた配列です。
3. アンアライントsuffix — これは以前と同様にfrom_iterで処理します。

middleは、入力の整数をサイズ16のチャンク（またはLANESに設定される任意のサイズ）に分割することをイメージしてください。それから私たちはis_consecutive関数を使ってチャンクを走査し、trueの範囲を検索します。各範囲は1つの連続範囲として扱われます。例えば、1000から1159の160個の個々の連続した整数の範囲は単一のRustのRangeInclusive 1000..=1159に置き換えられます。この範囲は、160個の個別の整数を処理するよりも遥かに速くfrom_iterで処理されます。もしis_consecutiveがfalseを返す場合、チャンク内の個々の整数をfrom_iterで処理します。

i128/u128

core::simdがハンドルしないi128/u128の配列をどのように扱いますか？現時点では、遅いfrom_iterで処理しています。

コンテキスト内ベンチマーク

最後のステップとして、SIMDコードをメインコードのコンテキストで、理想的には代表的なデータでベンチマークしてください。

range-set-blazeのクレートは、すでにベンチマークを含んでいます。1つのベンチマークでは、さまざまな密度で1,000,000の整数を取り込むパフォーマンスを測定しています。平均的な密度のクラムプサイズは1（クラムプなし）から100,000クラムプまでの範囲です。LANESを4、8、16、32、および64で実行してみましょう。アルゴリズムにはSplat1およびSIMDの拡張レベルavx512fを使用します。

各クラムプサイズについて、バーは1,000,000の整数を取り込む相対的な速度を示しています。各クラムプサイズにおいて、最速のLANESは100％に設定されます。

クラムプサイズが10と100の場合、LANES=4が最適です。ただし、クラムプサイズが100,000の場合、LANES=4は最適解から4倍も遅いです。逆に、クラムプサイズが100,000の場合、LANES=64は良さそうですが、クラムプサイズが100および1000の場合、最適解よりもそれぞれ1.8倍および1.5倍遅いです。

私はLANESを16に設定することにしました。これはクラムプサイズ1000に対して最も効果的です。さらに、最も良い解と比べても1.25倍以上遅くなることはありません。

この設定で他のベンチマークを実行できます。以下のチャートは、さまざまな範囲セットライブラリ（range-set-blazeを含む）が同じタスクで動作する様子を示しています-さまざまな密度の1,000,000の整数を取り込む。 y-軸はミリ秒で、値が小さいほど良いです。

クラムプサイズが1000の場合、既存のRangeSetBlaze::into_iterメソッド（赤）はすでにHashSet（オレンジ）よりも30倍速いです。スケールが対数です。 avx512fを使用する場合、新しいSIMD対応のRangeSetBlaze::into_sliceアルゴリズム（ライトブルー）はHashSetよりも230倍速いです。 sse2（ダークブルー）を使用する場合は220倍速いです。 avx2（黄色）を使用する場合は180倍速いです。このベンチマークでは、RangeSetBlaze::into_iterと比較して、avx512f RangeSetBlaze::into_sliceは7倍速いです。

最悪の場合も考慮する必要があります。つまり、クラムプがないデータを取り込む場合です。そのベンチマークを実行しました。既存のRangeSetBlaze::into_iterはHashSetよりも約2.2倍遅いことがわかりました。新しいRangeSetBlaze::into_sliceはHashSetよりも2.4倍遅いです。

したがって、バランスを考えると、新しいSIMDコードはクラムプのあるデータにとって非常に有益です。仮定が間違っている場合は遅くなりますが、致命的ではありません。

SIMDコードをプロジェクトに統合したら、出荷の準備が整ったはずですね？残念ながら、そうではありません。なぜなら、コードがRust Nightlyに依存しているため、オプションにする必要があるからです。次のルールでその方法を見ていきましょう。

ルール9：最良のSIMDアルゴリズムをプロジェクトから（現時点では）オプションのCargoフィーチャとして分離する。

私たちの美しい新しいSIMDコードは、Rust Nightlyに依存しており、定期的に変更されます。Rust Nightlyに依存することをユーザーに要求するのは冷酷です。（また、何かが壊れたときに苦情を受けるのは迷惑です。）解決策は、SIMDコードをCargoのフィーチャの背後に隠すことです。

Feature, Feature, Feature — SIMDとRustの作業の文脈において、「feature（機能）」という単語は3つの異なる意味で使用されます。まず、「CPU/target features（CPUの機能）」- これは、CPUの機能を表し、どのSIMD拡張をサポートしているかを含みます。 target-feature と is_x86_feature_detected!を参照してください。次に、「nightly feature gates（夜間の機能ゲート）」- Rustは、Rust nightlyでの新しい言語機能の可視性を feature gatesで制御します。例えば、#![feature(portable_simd)]です。3つ目は、「cargo features（cargoの機能）」- これにより、任意のRustクレートやライブラリが自身の機能の一部へのアクセスを提供/制限することができます。例えば、itertools/use_stdへの依存関係を追加する場合に、Cargo.tomlで見ることができます。

ナイトリーに依存するSIMDコードをオプションにするために、range-set-blazeクレートが取る手順は次のとおりです：

• Cargo.tomlで、SIMDコードに関連するcargo featureを定義します：

[features]from_slice = []

• トップのlib.rsファイルで、ナイトリーのportable_simdフィーチャーゲートがfrom_sliceのcargo featureに依存するようにします：

#![cfg_attr(feature = "from_slice", feature(portable_simd))]

• 条件付きコンパイル属性を使用し、たとえば#[cfg(feature = “from_slice”)]を使って、SIMDコードを選択的に含めます。これにはテストも含まれます。

/// 整数のコレクションから[`RangeSetBlaze`]を作成します。これは通常、[`from_iter`][1]/[`collect`][1]よりも多くの場合に高速です。/// 代表的なベンチマークでは、スピードアップ倍率は6倍でした。////// **注意：ナイトリーのコンパイラが必要です。また、`Cargo.toml`で`from_slice`フィーチャーを有効にする必要があります。たとえば、次のコマンドで：**/// ```bash///  cargo add range-set-blaze --features "from_slice"/// ```////// **注意**: `-C target-cpu=native`オプションでコンパイルすると、バイナリが現在のCPUアーキテクチャに最適化され、/// 異なるアーキテクチャを持つ他のマシンでの互換性の問題を引き起こす可能性があります。これは特にバイナリの配布や様々な環境での実行において重要です。/// [1]: struct.RangeSetBlaze.html#impl-FromIterator<T>-for-RangeSetBlaze<T>#[cfg(feature = "from_slice")]#[inline]pub fn from_slice(slice: impl AsRef<[T]>) -> Self {    T::from_slice(slice)}

• 上記のドキュメントに示されているように、ドキュメントに警告や注意を追加します。
• 自分のSIMDコードをチェックまたはテストするために、--features from_sliceを使用します。

cargo check --features from_slicecargo test --features from_slice

• --all-featuresを使用して、すべてのテストを実行し、すべてのドキュメントを生成し、すべてのcargo featureを公開します：

cargo test --all-features --doccargo doc --no-deps --all-features --opencargo publish --all-features --dry-run

結論

以上が、RustコードにSIMD演算を追加するための9つのルールです。このプロセスの容易さは、core::simdライブラリの優れた設計を反映しています。適用可能な場所では常にSIMDを使用するべきでしょうか？いずれにせよ、Rustのnightlyからstableに移行するまでは、パフォーマンスの利点が重要な場合にのみSIMDを使用するか、その使用をオプション化してください。

RustでSIMDのエクスペリエンスを改善するためのアイデアはありますか？core::simdの品質は既に高いですが、安定させる必要があります。

SIMDプログラミングの旅にご参加いただきありがとうございました。SIMD適用可能な問題がある場合は、これらの手順が助けになることを願っています。

CarlをVoAGIでフォローしてください。私はRustとPythonでの科学的プログラミング、機械学習、統計について書いています。通常、月に1つの記事を書いています。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!