muslのアロケータは「ひどい」—性能重視なら使うなとBifrost作者が警告
Don't use musl if you care about performance
JVMやPython中心の経歴を持つJonathan Ellis氏が、Rustプロジェクトでmusl libcに切り替えた後、同僚の指摘でmuslのアロケータ性能を測定。結果は「ひどい」もので、高並列時だけでなく4コアEC2 VMでも顕著だった。mimallocに交換してもglibc比26%遅く、アロケータ以外のメモリルーチンも遅いことが判明。muslはアロケータを同梱せず選択式にすべきと主張し、性能重視のBifrostではmuslをプリビルドオプションから外した。
「muslのアロケータは確かに悪い。いや、ひどい。そして（私が読んだいくつかの記事に反して）高並列シナリオだけの問題ではない。これらの数値は4コアのEC2 VMからのもので、Bifrostはそれに応じてスレッドプールをサイズ調整している。」
HNでの議論
59- matherial
アルゴリズムが大量の小さなアロケーションを行い、アロケータがボトルネックになるほどなら、そもそもやり方が間違っている。アロケータは多様なユースケースに対応し、断片化を避け、理想的にはさまざまなセキュリティチェックを実装する必要があるため、必然的に多くのオーバーヘッドが伴う。アロケーションが多い処理をしているなら、おそらく同じ構造体の割り当てと解放を繰り返しているだろうから、連続したメモリを確保して、タスク固有の方法で自分で管理する方がよい。
しかし現実には、ほとんど誰もパフォーマンスを気にしていない。なぜなら、少なくとも短期的には、計算コストよりも専門知識や人件費の方が高いからだ。すべてが肥大化して遅くなっているが、CPUコアやギガバイト、ギガヘルツを追加することで補っているだけだ。
- marssaxman
人によって視点は大きく異なる。26%遅いというのは、私には「ひどい」とは思えない。むしろ、muslが提供する利便性のために支払う合理的な代償のように思える。もしmuslのアロケータが2.6倍遅ければ「あまり良くない」と言うかもしれないが、「ひどい」と評価するには、桁違いの差が必要だと思う。
- bloppe
これは「パフォーマンス」の一側面にすぎない。glibcのアロケータは速いかもしれないが、メモリをより多く使用する。
もっと技術的な議論については、https://github.com/sharkdp/fd/issues/710 を参照。
- mattrighetti
先日もこれを投稿したが、muslアロケータの問題は広く知られているようだ [0]
- grep_it
リンクされたバイナリのサイズとシンプルさが常に主な特徴だったと思うのだが？