2026年8月6日(木)掲載 3,283本日 0
HN4511

メモリ速度で爆速処理!ソースコードのケースフォールディングで「早期終了」を避ける最適化手法

Don't stop early: Case-folding source code at memory speed

sbulaev5日前

議論

4
1claudetard約20時間前

良い技術記事なんだけど、AIが書いたのが見え見えだよね。

2pixelesque約20時間前

私たちが扱うのは主にソースコードなので、フォールドするテキストは圧倒的にASCIIが多く、メモリ速度で動作させることが何よりも重要です。それ以外の部分は、たまにある非ASCIIのパスのせいでパフォーマンスが落ちないようにするだけです。

話は少し逸れるけど、コーディングエージェント(仕事ではChatGPTとClaude、自宅ではDeepSeek 4とChatGPT)経由でLLMを使っていると、テスト値の範囲を示す矢印や、テスト結果の成否を示すチェックマークなどに、プレーンなASCII文字じゃなくてUnicodeや絵文字を使いたがる傾向があるみたいなんだよね。私の知る限り、コードベースはUTF-8ファイルであっても、ほぼ例外なくASCII文字で構成されているのに。

まだエージェントにコードを丸投げしているわけじゃない(コードレビューやプロトタイプの作成、テスト作成の補助に使うくらい)けど、近いうちにそうなっていくだろうし、そうしないようにプロンプトで指示すればいい話かもしれない。でも、これに気づいた人は他にもいないかな?もし非ASCII文字の出力が増えるのが一般的になったら、AI自体にとっても何かしら影響が出てくるのか気になっている。

3inigyou約19時間前

要約:オートベクタライゼーションを活用して、SIMDによるケースフォールディングを大幅に強化したって話だね。

ほとんどのフォールドはUTF-8の長さを維持するか短縮するが、例外としてU+023A (Ⱥ) と U+023E (Ɀ) の2つは、2バイトから3バイトの文字 (ⱥ, ɀ) に増えてしまう

これ、逆にすれば解決じゃない?ⱥをȺにフォールドするようにすればいい。そうすれば検索インデックスが小文字だけで構成されなくなるけど、そもそもそんなことは重要じゃないでしょ。