2016-04-23 10 views
2

いくつかのプログラムの最大のライブサイズをより正確に測定するために、より頻繁にガベージコレクションを実行するランタイムシステムを用意したいと思います。直接/間接的にGCを増やすGHCへのフラグはありますか?私はperformGCを挿入することがある程度はそれを達成することができます知っているが、楽器にはかなりのプログラムがあります。GHCでGCを増やすには?

+0

[GC設定](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime-control.html)で再生することは、おそらくメモリ使用量を測定する良い方法ではありません。結果依然として不正確な場合があります。 [GHCメモリプロファイリングページ](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/prof-heap.html)をご覧ください。 –

+0

@RafałRawickiプロファイリングは、最適化を妨げるため、私にとってはオプションではありません – rem

答えて

2

GCを直接増やすには、アイドルGCの頻度を増やすために-Isecondsフラグを0.3より低く設定します。 -cには、一般にメモリ使用量を減らすような圧縮アルゴリズムを使用するように設定することもできます(GCオーバーヘッドではなく実際のメモリに近い値にする)。 -Asizeを512kよりも低い値に設定することもできます。小さい割り当て領域を指定することで、通常はnoを増やす必要があります。のGCs。

0

あなたのコードに適したGCチューニングが特に分かっていない限り、より高い頻度のGCを強制するのはお勧めしません。 GCの実行は非常に高価になる可能性があります。

はい、あなたのプログラムは「あまりにも多くの」メモリを使いますが、この寛容さはGCがうまくいくようにするものです。厳密に必要とされるメモリの2〜3倍のオーバーヘッドを許容した場合(はGHCs GCの数値がわかりませんが、)、GC実行のスケジューリングはずっと少なくなります。

メモリプロファイリングを有効にしたくないと言うのは、最適化を妨げるためですが、強制的にGCを悪化させる可能性があります。ヒープの圧力を高めすぎると、GC実行のベンチマークが終了する可能性があります。

+0

おそらく私はこれを明確にしませんでしたが、これはパフォーマンスの問題ではありません。私の唯一の目的は、ライブサイズをより正確に測定することです。ランタイムシステムはGCからライブサイズの統計情報を取得するので、より頻繁にGCを使用すると、より多くの測定値が得られます。測定が良いほど、全体のパフォーマンスが悪化するかどうかは気にしません。 – rem

+0

@rem:OK、私はそれを誤解していました。別のコメントでは、プロファイリングが最適化を妨げていると言いました。私はパフォーマンスに関するものと仮定しました。 '-prof'だけでコンパイルしても、コストセンターには注釈をつけないと、プロファイリングが本当にあまりにも多くのパフォーマンスを必要とするかどうかをチェックしたいかもしれません。次に、 '+ RTS -hb'。サンプリング間隔を制御するために '-i'を追加してください。 – sapanoia

+0

「プロファイリングが実際にはあまりにも多くのパフォーマンスを必要とするかどうかをチェックしたいかもしれません」という点では、「パフォーマンスがあまりにも高すぎる」とは、実際のライブサイズよりもライブサイズに対するオーバーヘッドを意味します。しかし、実際のライブサイズの正確な測定がないかどうかをどのように伝えますか? – rem

関連する問題