検索スレッドは何本が正解か — 8.9億行を1〜16スレッドで実測した

大きなテキストを並列検索するとき、スレッドは何本にすべきか。「コア数ぶん」「コア数×2」「物理コアまで」——通説はいろいろありますが、自分のアプリの、実物のデータで測った数字がいちばん信用できます。

UwView Pro の検索エンジンを、8.9億行の実データに対して1〜16スレッドで実測しました。結論から書くと、8スレッドで頭打ち（1スレッド比3.0倍）。10コアのマシンなのに、です。

測り方を全部見せる

• マシン: MacBook Air（Apple M4／10コア＝性能4P＋効率6E／RAM 32GB／電源接続）
• データ: OpenStreetMap 日本 japan-latest.osm（元48GB・8.9億行）の圧縮キャッシュ .uwvz（5.3GB）
• 対象: 検索エンジン単独起動（search-standalone）。UIやファイルオープンは含まない
• 条件: warm（キャッシュ温）。cold（キャッシュ破棄後）は今回測っていません
• 計測: 1〜16スレッドを1周する掃引を4ラウンド繰り返し（ラウンドロビン）、各スレッド数はラウンド間の中央値。全128計測

なぜ「1スレッドから順に測る」ではなくラウンドロビンなのか。ファンレスのM4は連続負荷で熱制限がかかり、測定順序が結果に系統誤差として乗るからです。この話は失敗談込みで別記事（ファンレスMacでベンチを取ったら54%ブレた）にまとめました。本記事の数値はすべて是正後のものです。

結果

検索語は、ヒット件数が大きく違う2種類を選びました。

（単位: 秒。4ラウンドの中央値）

読み — 3つの事実

1. 8スレッドで頭打ち。1スレッド22.2秒→8スレッド7.4秒（3.0倍）。 以降16スレッドまで7.4〜8.2秒の横ばいです。増やしても速くなりませんが、16まで積んでも目立った悪化はありませんでした（オーバーサブスクのペナルティは小さい）。

2. 頭打ちの位置は「コア数」ではない。 このマシンは性能コア4＋効率コア6の10コアです。頭打ちは全コア数10の手前の8で来て、しかし性能コア数4よりはずっと先。P/Eどちらか一方のコア数では説明できない位置です。「スレッド数はコア数に合わせる」という通説をここに当てはめると、10を選んで8と同じ速度（損はしないが得もしない）、4を選ぶと10.2秒で27%遅くなります。

3. ヒット件数は無関係。 10,967件と722件、ヒット数が十数倍違う2つの検索語で、曲線がほぼ完全に一致しました。この検索の仕事量は「見つける件数」ではなく「走査する量」が支配的だ、ということです。

もうひとつ細かい観察を。スケーリングは最初から逓減しています。2スレッドで1.6倍（理想は2倍）。並列化のオーバーヘッドとメモリ帯域の取り合いは、2本目からすでに始まっています。

制約（正直に）

• 数字はすべてwarm。coldは測っていません
• 計測は1台（MacBook Air M4）のみ。CPU数・メモリを振った比較は別企画として準備中です
• 17スレッド以上は未計測

製品への着地 — だから「自動」にした

この実測が言っているのは、「このマシン・このワークロードでは8本前後が正解で、外すと損をする」です。そして正解の位置はマシンによって変わりうる。ユーザーにスレッド数を選ばせる設定項目は、正解を外させる装置にしかなりません。

なので UwView Pro はスレッド数を自動で選びます（UWV_SHARDS=auto が既定）。ユーザーは何も設定しなくてよい。この計測は、その「自動」の中身を決めるための計測でした。

そして、ストレージを専有している巨大ログを圧縮して保管し、さらに高速に検索したいなら UwView Pro をどうぞ。永続索引・圧縮キャッシュ検索・約1/9保管で、開き直しも検索も一段速くなります（全OS対応・買い切り $129／月額 $9）。

開発者より: アプリ・Kindle本・オープンソースの一覧は GitHub: amru195704 にまとめています。

お願い
本記事の情報は参考目的で掲載しており、正確性・完全性を保証するものではありません。機能の有無は各バージョン時点の確認であり、今後のアップデートで変わる可能性があります。誤記・不正確な情報がございましたら、コメント欄よりご指摘いただければ、確認のうえ修正いたします。