Am 18.12.2011, 23:15 Uhr, schrieb bearophile <[email protected]>:
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.
