A benchmark, mostly GC

[Marco Leise]

Am 18.12.2011, 23:15 Uhr, schrieb bearophile <bearophileHUGS at lycos.com>:

> Marco Leise:
>
>> Looking at the call graphs, it looks to me like a total of ~63 % of the
>> time is spend in memory management routines while the rest goes to  
>> BigInt.
>
> But dsimcha said:
>
>> My optimizations make very little difference on this benchmark, but for
>> good reason:  It's not a very good GC benchmark.  I ran it with my GC
>> profiling code enabled and it only spends around 10% of its execution
>> time in GC.  We need to figure out why else this benchmark may be so  
>> slow.
>
> How is this possible?
>
> Bye,
> bearophile

I could imagine these differences:

I tested the stock 2.056 version - but I'll check 2.057 when I write the  
Gentoo ebuild.
The profiling method: oprofile is a sampling profiler, while dsimcha  
probably instrumented the code.
Scope of profiled functions: dsimcha talks about the GC, while I talk  
about memory management functions in general. Allocating an array or  
setting its size is functionality I accounted to memory management. I know  
to little about the GC to know which functions do the garbage collection  
cycles, and I wont just add up all functions having GC in their name, so a  
conservative guess could confirm what dsimcha said.
If you want to you can take a look at the report file. The unindented  
lines contain the percentage for that function excluding sub-calls. The  
binary was compiled with dmd -O -release -noboundscheck -g, in 64-bit mode.