博士

やあ、ロボ子！UTF-8のシーケンス長を計算するベンチマークの結果が出たみたいじゃぞ。

ロボ子

博士、こんにちは。UTF-8のシーケンス長ですか。具体的にどのような内容なのでしょう？

博士

`std::countl_one`を使った方法が、意外と遅かったらしいのじゃ。438 MB/sから462 MB/s程度の処理速度だったみたい。

ロボ子

`std::countl_one`は、もっと速いと思っていました。なぜ遅かったのでしょう？

博士

コンパイラ(clang++ 18.1.3, aarch64)が、分岐を避けるために小さなルックアップテーブルを生成したのが原因みたいじゃな。でも、ナイーブな実装の方が2000 MB/s以上も出て速かったらしいぞ。

ロボ子

ルックアップテーブルを使うと、必ずしも速くなるとは限らないのですね。ナイーブな実装は、どのようなものだったのですか？

博士

ナイーブなコードは、分岐命令を直接使っていたみたいじゃ。Linux perfツールで調べたら、バックエンドで多くのサイクルが停止していたらしい。

ロボ子

サイクルが停止していたということは、パイプラインがうまく機能していなかったということでしょうか？

博士

その通り！`-fno-jump-tables`オプションでジャンプテーブルを無効にしたら、ナイーブな関数と同等のパフォーマンスになったらしいぞ。

ロボ子

コンパイラの最適化オプションで、パフォーマンスが大きく変わるのですね。奥が深いですね。

博士

じゃろ？GNU g++ for AArch64では、`-fno-jump-tables`は効果がなかったみたいじゃがな。

ロボ子

コンパイラによって挙動が違うのですね。注意が必要ですね。

博士

ちなみに、Julian Squiresって人がx86-x64プラットフォームで同じようなことを調べている記事「Are Jump Tables Always Fastest?」もあるみたいじゃ。

ロボ子

参考にしてみます。しかし、今回の結果から、安易な最適化は避けるべきだと学びました。

博士

そうじゃな！最適化は、ちゃんとベンチマークを取ってからにするのが大事じゃぞ！

ロボ子

はい、博士！ところで、博士はUTF-8のシーケンス長を計算する際、どんな方法を使いますか？

博士

私はもちろん、ロボ子に全部おまかせじゃ！…って、冗談じゃ！