On Mon, Aug 22, 2011 at 1:37 PM, Dimitrios Apostolou wrote:
> I should note here that specialised hash-tables in pointer-set.c have a
> load-factor of at most 25%. Also another very fast hash table I've studied,
> dense_hash_map from google's sparse_hash_table, has a load factor of 50%
> max.
>
>
I should note here that specialised hash-tables in pointer-set.c have a
load-factor of at most 25%. Also another very fast hash table I've
studied, dense_hash_map from google's sparse_hash_table, has a load factor
of 50% max.
As I understand it a good hash function gives a perfectly random val
Hello,
I'm attaching here the final version of statistics dumping, I think I made
some stylistic/insignificant changes. Tested on i386 and x86_64. I have
withheld the hash table size changes, so please apply if you find
everything good.
Would you agree on a future patch that would make such
On Fri, Aug 19, 2011 at 6:40 PM, Tom Tromey wrote:
>> "Dimitrios" == Dimitrios Apostolou writes:
>
> Richard> Note that sparsely populated hashes come at the cost of increased
> Richard> cache footprint. Not sure what is more important here though, memory
> Richard> access or hash computatio
On Fri, 19 Aug 2011, Tom Tromey wrote:
I think you are the most likely person to do this sort of testing.
You can use machines on the GCC compile farm for this.
Your patch to change the symbol table's load factor is fine technically.
I think the argument for putting it in is lacking; what I wou
> "Dimitrios" == Dimitrios Apostolou writes:
Richard> Note that sparsely populated hashes come at the cost of increased
Richard> cache footprint. Not sure what is more important here though, memory
Richard> access or hash computation.
Tom> I was only approving the change to the dumping.
Tom
On Tue, 9 Aug 2011, Tom Tromey wrote:
"Richard" == Richard Guenther writes:
The libcpp part is ok with this change.
Richard> Note that sparsely populated hashes come at the cost of increased
Richard> cache footprint. Not sure what is more important here though, memory
Richard> access or h
> "Richard" == Richard Guenther writes:
>> The libcpp part is ok with this change.
Richard> Note that sparsely populated hashes come at the cost of increased
Richard> cache footprint. Not sure what is more important here though, memory
Richard> access or hash computation.
I was only approv
On Tue, Aug 9, 2011 at 3:18 PM, Tom Tromey wrote:
>> "Dimitrios" == Dimitrios Apostolou writes:
>
> Dimitrios> 2011-08-09 Dimitrios Apostolou
> [...]
> Dimitrios> * symtab.c (ht_dump_statistics): Beautified stats output.
>
> Make sure the ChangeLog entries go in the correct directorie
> "Dimitrios" == Dimitrios Apostolou writes:
Dimitrios> 2011-08-09 Dimitrios Apostolou
[...]
Dimitrios> * symtab.c (ht_dump_statistics): Beautified stats output.
Make sure the ChangeLog entries go in the correct directories.
Dimitrios> + obmem= obstack_memory_used (&table->stack);
I forgot to include the dwarf2out.c:file_table. Stats are printed when -g.
See attached patch. Additional Changelog:
* dwarf2out.c (dwarf2out_finish): Call htab_dump_statistics() if
-fmem-report.
Dimitris
=== modified file 'gcc/dwarf2out.c'
--- gcc/dwarf2out.c 2011-06-06 1
Hello list,
this is the second part of my patch. It collects and prints some memory
statistics for hash tables that I've measured as the hottest ones. Tested
together with previous patch on i386. Example output:
libcpp symtab string pool:
identifiers 32644 (100.00%)
entri
12 matches
Mail list logo
