メモリ速度で爆速処理!ソースコードのケースフォールディングで「早期終了」を避ける最適化手法
Don't stop early: Case-folding source code at memory speed
Don't stop early: Case-folding source code at memory speed
ソースコードのケースフォールディング(大文字・小文字の正規化)において、処理を途中で打ち切るのではなく、メモリ帯域をフル活用して全データを高速に処理するためのアプローチについての考察です。
良い技術記事なんだけど、AIが書いたのが見え見えだよね。
私たちが扱うのは主にソースコードなので、フォールドするテキストは圧倒的にASCIIが多く、メモリ速度で動作させることが何よりも重要です。それ以外の部分は、たまにある非ASCIIのパスのせいでパフォーマンスが落ちないようにするだけです。
話は少し逸れるけど、コーディングエージェント(仕事ではChatGPTとClaude、自宅ではDeepSeek 4とChatGPT)経由でLLMを使っていると、テスト値の範囲を示す矢印や、テスト結果の成否を示すチェックマークなどに、プレーンなASCII文字じゃなくてUnicodeや絵文字を使いたがる傾向があるみたいなんだよね。私の知る限り、コードベースはUTF-8ファイルであっても、ほぼ例外なくASCII文字で構成されているのに。
まだエージェントにコードを丸投げしているわけじゃない(コードレビューやプロトタイプの作成、テスト作成の補助に使うくらい)けど、近いうちにそうなっていくだろうし、そうしないようにプロンプトで指示すればいい話かもしれない。でも、これに気づいた人は他にもいないかな?もし非ASCII文字の出力が増えるのが一般的になったら、AI自体にとっても何かしら影響が出てくるのか気になっている。
要約:オートベクタライゼーションを活用して、SIMDによるケースフォールディングを大幅に強化したって話だね。
ほとんどのフォールドはUTF-8の長さを維持するか短縮するが、例外としてU+023A (Ⱥ) と U+023E (Ɀ) の2つは、2バイトから3バイトの文字 (ⱥ, ɀ) に増えてしまう
これ、逆にすれば解決じゃない?ⱥをȺにフォールドするようにすればいい。そうすれば検索インデックスが小文字だけで構成されなくなるけど、そもそもそんなことは重要じゃないでしょ。