最近、メモリを多く使うプログラムで巨大（1GB）ページをうまく使うために、Microsoftのmimallocを使い始めたんだ（LD_PRELOAD経由で）。パフォーマンスの向上はかなり大きくて、約20%も上がったよ。LinuxシステムでオープンソースのMSライブラリを使うのはちょっと変な感じだけど、mallocの世界にはもっと競争が必要だと思う。さまざまな巨大ページサイズや透過的巨大ページを考えると、デフォルトのGNU libcよりも得られる利点はたくさんあるよね。

GC言語の一番いいところは、メモリの割り当てや解放がすごく効率的になることだよね。コストがまとめられているから、プロファイルにもはっきり現れるし。

Dr DobbsやC/C++ユーザーズジャーナル、BYTEのデジタルアーカイブに行くと、特別にケース分けされたメモリアロケータを持つ会社の広告があるよ。MS-DOS用のTurbo Pascalみたいなツールチェーンでも、メモリアロケータをカスタマイズするためのAPIがあったし、全てに合う一つの解決策なんてなかったんだよね。

jemallocを10年以上使ってるけど、アップデートする必要はあまり感じないな。新しいmallocが出ても、ベンチマークではいつも良い結果を出してるし。最後にmimallocをチェックしたのはかなり前、たぶん5年前だけど、明らかに劣ってたし、GitHubのイシューでも同意する人が多かったから、もう見なくなっちゃった。

ちょっと気になるんだけど、Xeonか他のプラットフォームで1GBの巨大ページを使ってるの？このクラスのページは、確かTLBスロットが1つしかないから、利用するのが一番難しいと思ってたんだけど。

本当に変わるべきなのは、malloc/reallocだけじゃなくて、もっと表現力のあるメモリ割り当てインターフェースが必要だと思う。プログラムが何をしようとしているのか、もっと情報があれば、メモリアロケータはかなり良い仕事ができるはずだよ。

zenlispをOpenBSDで動かすためにmimallocを使ったんだけど、ベースのパラノイドmallocとぶつかっちゃうからね。

多くの場合、mallocを使うよりも良い方法があるよ。例えば、巨大なページが必要だとわかっているなら、mmapで直接巨大なページをマップすればいい。もし任意のalloc/freeを使いたいなら、サードパーティのmallocを使うのがいいよ。alloc/freeのパターンが任意でないなら、もっと良い結果が出せる。mallocは魔法のブラックボックスみたいに扱われてるけど、実際はあんまり良くないんだよね。

いくつかのLinuxアプリのためにいくつかのアロケーターを評価した結果、(現代の) tcmallocが時間とスペースの面で一貫して勝ってることがわかった。私たちのアプリは主にRustで書かれていて、アロケーターは静的にリンクされてた（glibcを除いて）。残念ながら、アロケーションパターンについてあまり文脈をキャッチできなかったけど、一般的にアプリはほとんどのRustアプリよりも高いレートでアロケートとデアロケートしてると思う（少なくとも私が望むよりも）。2025年7月の結果はこんな感じ：行は、app1: glibc: 215,580 KB, 133 ms mimalloc 2.1.7: 144,092 KB, 91 ms mimalloc 2.2.4: 173,240 KB, 280 ms tcmalloc: 138,496 KB, 96 ms jemalloc: 147,408 KB, 92 ms app2, bench1 glibc: 1,165,000 KB, 1.4 s mimalloc 2.1.7: 1,072,000 KB, 5.1 s mimalloc 2.2.4: tcmalloc: 1,023,000 KB, 530 ms app2, bench2 glibc: 1,190,224 KB, 1.5 s mimalloc 2.1.7: 1,128,328 KB, 5.3 s mimalloc 2.2.4: 1,657,600 KB, 3.7 s tcmalloc: 1,045,968 KB, 640 ms jemalloc: 1,210,000 KB, 1.1 s app3 glibc: 284,616 KB, 440 ms mimalloc 2.1.7: 246,216 KB, 250 ms mimalloc 2.2.4: 325,184 KB, 290 ms tcmalloc: 178,688 KB, 200 ms jemalloc: 264,688 KB, 230 ms tcmallocはgithub.com/google/tcmalloc/tree/24b3f29からのもの。どのjemallocがテストされたかは覚えてない。

ウェブサービスの初期の頃、apache portable runtimeを使って、特にメモリプールを利用していたのを思い出す。ウェブリクエストが来ると、そのためにメモリプールを割り当てて、そこからすべてのメモリ割り当てを行うんだ。そして、ウェブリクエストが終わるときには、きれいに終わるか、いろんなエラーが出るかに関わらず、そのプール全体を解放するだけで済む。すごく便利で、印象に残ったな。mallocもいろいろ面白い成長や変化があると思うよ。

オペレーティングシステムの改善があれば、もっと多くの人が巨大ページを使う気になると思うな。特に、Linuxでは壊れにくくして、Windowsでは管理者権限がなくても使えるようにしてほしい。問題の一番の要因は、どちらのOSも2MBのページをスワップできないことなんだよね。だから、誰かがそれを直すことに気を使う必要がある。

関連情報。他にも？ Jemallocのポストモーテム - https://news.ycombinator.com/item?id=44264958 - 2025年6月（233件のコメント） Jemallocリポジトリはアーカイブ済み - https://news.ycombinator.com/item?id=44161128 - 2025年6月（7件のコメント）

これは世界的なメモリ不足が原因なのかもしれないね。「ああ、メモリアロケータをもっと効率的にすれば、来年には$XXMの節約ができる」って感じで。

単なる不足だけじゃなくて、LLMや電力、サーバーのメモリフットプリントの改善が、時間が経つにつれてますます価値が出てきてるよね。もし10%速くできれば、LLMレースで簡単にリードを取れる。パフォーマンスを透明に改善するインセンティブはすごく大きい。

コストに加えて、注文したメモリをタイムリーに手に入れるのが難しいから、今は効率を上げることが重要だよね。

Facebookは10年以上前にすでに話をしてたけど、実際の数字を共有することは許されてなかった。でも、数人のFacebookの社員が、会社が最適化からの節約を測定したことを共有することは許されてた。行間を読むと、Facebookの一部で0.1%の効率改善があれば、月に10万ドルの節約になるってこと（実際の数字は公開されてないから範囲があるけど、2万ドル未満ではない）。だから、そういう改善を見つけるためのチームがいたんだ。ほとんどの節約はHVACコストから来てるようで、その次がコンピュータを少なく買うこと、そしてデータセンターも少なくなるって感じ。今はメモリを節約することも大事だと思うけど、当時はそうでもなかったみたい。上記のことは10年前からそうだったから、LLMはせいぜいもう一つの要因が加わっただけだね。

そうだね、Metaではプロファイルから数百万の節約を特定するのは比較的一般的な手法だよ。非常に多くのサーバーに影響を広げると、大きな数字を出すのは簡単だしね。こういう定量的な成果を測定して文書化する文化があるんだ。

おお、もしかしたら手作業で最適化されたアセンブリが再び流行る時が来るかも！(AIのワークロードではもう流行ってるかも、なんて夢見てる)

あの会社の評判を考えると、メモリ不足よりもさらに落ち込むようなバックストーリーがたくさんあるんじゃないかと思う。

> メモリアロケーターを変更して、彼らは2009年からjemallocを使って「je」を採用している。

> ダーウィンでの辛い経験から、内部で孤立したオープンソースプロジェクトはうまくいかないってわかってた（HHVMは繰り返しの教訓だった）。HHVMがあったことには感謝してるし、停滞したことにも感謝してる。PHP 7と8は、HHVMが彼らを叩かなければ、あんなに改善できなかったと思うし、HHVMがその公の勢いを失ってなければ、PHP 8よりもHHVMに基づくフォークがあっただろうね。WikimediaがHHVMのテストや部分実装をしてたのを覚えてるけど、少なくとも当時私がいたサークルでは転機だった。PHPのパフォーマンスが実際に改善できることを示したし、かなりの改善だった。あの規模でのオープンな概念実証がなければ、HHVMの開発者たちは永遠にベンチマークを走らせてたかもしれないけど、人々は「そうだね、もしFacebookなら」と言ってたと思う。

このストーリーのURLがMetaのプレスリリースに変わったみたい。何を引用してるの？

世界銀行が資金提供したスタートアッププロジェクトのシニアリードソフトウェアエンジニアだった時のことを覚えてる。プロダクションでRubyをjemallocでデプロイしたんだ。速度とメモリ効率がすごく改善されたよ。普通のRubyを使うよりもAWSコストがかなり節約できた。これが8年前の話なんだけど、どうしてプロジェクトがまだデファクトスタンダードとして採用してないのか不思議だね。

> 「[..] パージメカニズムの改善を提供する予定です。私がFacebookにいた頃、jemallocのパージメカニズムを改善するためのカーネルパッチをいくつか維持していました。カーネルやセキュリティコミュニティでは人気がありませんでしたが、ベンチマークでは確実に効率的でした。多くのプログラムは複数のスレッドを実行し、一つのスレッドで割り当てて、別のスレッドで解放します。jemallocの主なメカニズムは、ページをカーネルに戻して、別のスレッドのプールで割り当てることでした。一つの問題は、メモリをゼロクリアすることが必要で、これがキャッシュのローカリティやアプリ全体のパフォーマンスに影響を与えることです。同じセキュリティドメイン内でページが再循環している場合、これは完全に不要です。そのセキュリティドメインが何であるかについて、みんなが合意するのが問題でした。たとえそのメカニズムがオプトインであっても。」

自分たちのフォークで取り組んできたものを一気にマージして強力にスタート！: https://github.com/jemalloc/jemalloc/pull/2863

グローバルメモリ供給ショックについての言及がないのは驚きだね。この経済がソフトウェアの優先順位をメモリ割り当てに向けてシフトさせていることについて、もっと知りたいな。私の（比較的若い）キャリアでは初めてのことだから。

直接関係があるように見えるかもしれないけど、実際はそうじゃないんだ。RAMが安くても高くても、これらのことは進められている。メモリのフットプリントを最適化することは、ほぼ常にリースするマシンを減らすことにつながるから、小さなショップにとっても価値のある目標なんだよ。

ハイパースケーラー規模での衝撃があったよ。例えば、これがGoogleで数年間大きくなったのは、ChatGPTの前だった。

> ソフトウェアシステムを構築するのは、高層ビルを建てるのと似てる。みんなが見るのは上の部分だけど、倒れないように支えているのは土の中に埋まっている基礎や、目に見えない足場なんだ。彼らはただ「アイボリートワー」と呼ぶべきだった。そうすれば、OSのバックドアロビー活動やケンブリッジ・アナリティカの悪ふざけで民主主義を壊してないときに、何を作っているのかがわかるから。編集：イーロン・マスクの会社に関するスレッドには、少なくとも10件のコメントが彼の人類に対する犯罪について語っているけど、ザッカーバーグの会社に関するスレッドには、少なくとも1件のコメントがあってもいいよね。こういうリマインダーがないと、先週の話みたいなのはどうでもいいことになっちゃうかも。

アロケーターを最適化する必要があるなら、やり方が間違ってるよ。