「もうやらなくていい昔のコーディングテクニックあれこれ」記事へのコメント

時々思うんだが

[gonta (11642)]

malloc/freeの処理コストってどれくらいかかるんだろう。メモリがバカ高かった時代はmalloc/freeで使用量を厳密に、というのはわかるんだが、ンGB当たり前の昨今、malloc/freeの処理コストの方が高くなったりしないのかな？と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。

・・・malloc/free叩いとらんな、最近。

--
-- gonta --
"May Macintosh be with you"

Re:時々思うんだが

[entaille (15816)]

malloc/freeはシステムコールなので呼ぶとコンテキストスイッチが発生します。
特にCPUのクロック数よりもL2キャッシュのヒット率とかのほうが性能的影響が
大きいようなメモリレイテンシにシビアなシステム、例えば、
マルチスレッドでサイズの大きいヒープを頻繁に生成／開放しながら
沢山のアクセスを受け付けるサーバーアプリみたいな処理系では、
コンテキストスイッチのオーバヘッドが馬鹿にならないので、
JVMや.Netのようにヒープの大枠確保しておいて、プロセス内部で
cpu user timeでやりくりするメモリ管理があったほうが性能的には有利。
というもんだと理解しとります

Re:時々思うんだが

[CowardDuck (25674)]

> malloc/freeはシステムコールなので呼ぶとコンテキストスイッチが発生します。

malloc/free はシステムコールではありません。必要であれば mmap や brk などで
ヒープの大枠を確保し、確保したヒープを切り分けること自体はユーザモードで
行います。

というわけで、

> JVMや.Netのようにヒープの大枠確保しておいて、プロセス内部で
> cpu user timeでやりくりするメモリ管理があったほうが性能的には有利。
> というもんだと理解しとります

JVMや.Net のメモリ管理方式には C に対してあなたが述べたような性能的な
アドバンテージはありません。

Re:時々思うんだが

[CowardDuck (25674)]

失礼。

ページフォルトの影響を書き忘れてました。

そうだな。。。

ページフォルトが後からじんわり効いてくるのがいやな場合には
プログラムの初期化部分で大きめに malloc して memset してから
free しとく必要がありますね。

でも JVM でもこれを避けようとしたら JVM 自体の初期化処理で
同じことをやる必要があるはず。ですんでこれは性能的な
アドバンテージというよりは、プログラムを数～十数ステップ程度、
短くできるかどうかという問題ですね。

この意味でのアドバンテージなら確かにありますね。

Re:

[Anonymous Coward]

>ページフォルトが後からじんわり効いてくるのがいやな場合には
>プログラムの初期化部分で大きめに malloc して memset してから
>free しとく必要がありますね。

メモリに十分な余裕がある場合、（ページアウトしているデータを復元するのではなく）単に新しい物理ページ割付のためのフォルトが気になることって、ありますかね？

逆にそのレベルでも気になる状況なら、memsetくらいではダメで、plock等の物理メモリロックを使わないとダメでしょう。