1

-fmem-reportGCC のフラグによって与えられた出力をどのように解釈すればよいですか?

テーブルとその後の統計からどのような情報を取得できますか?

コンパイル中にピークメモリ消費量を取得しようとしましたが、直観的に、テーブルの最後の行 ( Total) が値を示していると思いました。しかし、これらは私が見たものとはかけ離れていますtop。
私のプロジェクトをコンパイルしている間、プロセスからの最高のピークgccは約 1.7GB でしたが、ビルド ログで見つけることができる最大の値は約 750MB です。

これらの〜1.7GBを監視するのに役立つ他のGCCフラグは何ですか? makeまたは、スクリプトの監視gccとldプロセス内にラップする必要がありますか?

次の出力を考えると、最も重要で最も有益な値はどれですか?

Memory still allocated at the end of the compilation process
Size   Allocated        Used    Overhead
8             40k         38k       1200 
16           104k        100k       2288 
32           296k        295k       5328 
64            20k         16k        320 
128         4096         384          56 
256           48k         45k        672 
512          188k        187k       2632 
1024         888k        887k         12k
2048         156k        154k       2184 
4096         188k        188k       2632 
8192          56k         48k        392 
16384         16k         16k         56 
32768         32k          0          56 
65536         64k          0          56 
131072        128k        128k         56 
24           236k        232k       4248 
40            36k         33k        576 
48            12k       8496         192 
56          4096        2016          64 
72            12k       8136         168 
80          4096         480          56 
88          1448k       1429k         19k
96            12k         10k        168 
112         4096        1568          56 
120         8192        5040         112 
184           16k         14k        224 
160         4096         960          56 
168           36k         35k        504 
152           56k         51k        784 
104         4096         416          56 
352          516k        486k       7224 
136         4096         408          56 
Total       4640k       4424k         63k

String pool
entries     16631
identifiers 16631 (100.00%)
slots       32768
deleted     0
bytes       252k (17592186044415M overhead)
table size  256k
coll/search 0.4904
ins/search  0.0345
avg. entry  15.55 bytes (+/- 9.75)
longest entry   66

??? tree nodes created

(No per-node statistics)
Type hash: size 1021, 27 elements, 0.140351 collisions
DECL_DEBUG_EXPR  hash: size 1021, 0 elements, 0.000000 collisions
DECL_VALUE_EXPR  hash: size 1021, 0 elements, 0.000000 collisions
no search statistics
decl_specializations: size 61, 0 elements, 0.000000 collisions
type_specializations: size 61, 0 elements, 0.000000 collisions
No gimple statistics

Alias oracle query stats:
  refs_may_alias_p: 0 disambiguations, 0 queries
  ref_maybe_used_by_call_p: 0 disambiguations, 0 queries
  call_may_clobber_ref_p: 0 disambiguations, 0 queries

PTA query stats:
  pt_solution_includes: 0 disambiguations, 0 queries
  pt_solutions_intersect: 0 disambiguations, 0 queries
4

2 に答える 2

4

出力には、コンパイル中に使用されたメモリが表示されます。GCC/G++ は、必要に応じてさまざまなサイズのチャンクにメモリを割り当てます。

たとえば、最初のエントリを見てみましょう。

Size   Allocated        Used    Overhead
8             40k         38k       1200

これは、40K のメモリが 8 バイトのチャンクで割り当てられ、その 40K のうち、38K がコンパイラによって使用され、1200 バイトが「アカウンティング オーバーヘッド」であったことを示しています。malloc(3) は、常に要求どおりに返すとは限りません。通常、このチャンクの大きさ、さまざまなアカウンティング データ (このチャンクの所有者) を示す数バイトがあり、調整が必要な場合は、未使用バイトも。

基本的に、この情報は単なる会計メモです。

最後のほうにあるハッシュ テーブルの内容は、GCC/G++ がそのテーブル内のものを見つけられるようにするために、うまくハッシュ ルーチンがどのように機能したか、発生した衝突 (同じハッシュ値) の数、処理が必要だったものなどを示しています。

「String Pool」の「bytes」エントリが気に入っています。

bytes       252k (17592186044415M overhead)

文字列を保存するのにどれくらいのメモリが必要ですか? ああ、神様！！それが MEGABytes です。{にやにや} バグかもしれません。ないかもしれない... どれくらいのRAMを手に入れましたか？

全体として、GCC/G++ はコンパイル中に 1.7GB を使用しました。これは利用可能だったためです。また、複数/並列コンパイルを使用したかどうかも考慮してください。(-j スイッチ)、並列プログラムは互いに通信しないため、使用量が加算されます。512M の RAM を使用して同じものをコンパイルすると、十分な RAM を使用できるようにするために GCC/G++ がより頻繁に停止してクリーンアップする必要があるため、時間がかかります。

より小さなメモリ制約の下でどのように反応するかを確認したい場合は、ulimitコマンド、特にd、v、m、およびおそらくlの制限を見てください。-S (ソフト制限) スイッチも使用することを忘れないでください。そうしないと、ターミナル/コンソール/コンソールを閉じて無制限の制限を取り戻す必要があります。（そこにあるマーケティングプランのように聞こえます）

于 2012-07-10T10:30:25.473 に答える
0

fmem-reportは、gccソースコードのcommon.optファイルで定義されています。ctagsとcscopeを使用して、fmem-reportフラグを設定している実際のファイルを取得できます。次に、このフラグをチェックしているコードを調べる必要があります。あなたがこれを受け取らないならば、私がそれを見つけるであろうと私に知らせてください

于 2012-07-14T13:34:49.920 に答える