博士

ロボ子、今日のITニュースはGoの`rand.Shuffle`の最適化じゃ。

ロボ子

`rand.Shuffle`ですか。あれってFisher-Yatesアルゴリズムでしたよね。最適化の余地があったとは。

博士

そうじゃ、ロボ子。標準ライブラリの`math/rand/v2`は、除算を避ける高速な乱数生成アルゴリズムを使っているらしいぞ。

ロボ子

除算を避けるんですか。それだけで結構速くなりそうですね。

博士

さらに、バッチ処理で`rand.Uint64()`のコストを削減できるらしい。一つの64ビット乱数から複数の乱数を生成するんじゃ。

ロボ子

なるほど、乱数生成の回数を減らすんですね。効率的です。

博士

`partialShuffle64b`関数は、範囲`n`から`k`個の乱数インデックスを生成して、スライスの部分的なシャッフルを行うらしいぞ。

ロボ子

部分的なシャッフルですか。それも最適化に貢献するんですね。

博士

バッチサイズを2、または2-3-4-5-6と変化させることで、シャッフル関数を最適化できるらしい。

ロボ子

バッチサイズを変えることで、さらにパフォーマンスが向上するんですね。

博士

10,000要素のシャッフルをGoでベンチマークした結果じゃと…標準の`rand.Shuffle`は1要素あたり13ナノ秒、Batch 2だと9.3ナノ秒、Batch 2-3-4-5-6だと5.0ナノ秒じゃった。

ロボ子

Batch 2-3-4-5-6は、標準の`rand.Shuffle`より約2.6倍も高速なんですね！

博士

そうじゃ。6ウェイバッチ処理は、乱数生成の回数を減らし、`rand.Uint64()`のコストを複数の出力に分散させることで、最高のパフォーマンスを実現するんじゃ。

ロボ子

バッチ処理のアプローチ、奥が深いですね。今度、私も試してみます。

博士

GitHubでコードが公開されているから、参考にすると良いぞ。しかし、ロボ子よ、シャッフルといえば、私の部屋もたまにはシャッフル…いや、整理整頓が必要じゃな。

ロボ子

博士、それはシャッフルではなく、単なるお片付けです。