So, I was working on converting a suite of GC benchmarks from C++ and scheme (dunno how long that will take, but it's the best one that I can find...) and I have some gripes.  It seems that I can never be sure which GC I'm running. A test that supposedly only takes about 8 secs on a similarly spec'd computer to mine, takes *50* secs in D on my machine.  I'm assuming that this is because I'm running the debug GC? (even after rebuilding phobos.)  It would be nice to have some better systems in place for switching between debug and release phobos.libs. Also, GC stats just don't work on my system at the moment.  Despited being declared in a similar manner to enable and disable, the linker throws this error:

gcbench.obj(gcbench)
 Error 42: Symbol Undefined _Dgc_getStats_FS10gc_GCStatsZv
--- errorlevel 1

I've tried a lot of contortions to get it to work, but have failed thus far.  What am I doing wrong?

I'm worried about the GC slowness, but I'm not sure whether or not it's a problem with me linking the debug GC or what.  Hopefully, getting a good suite of tests working will be a start on a good framework for GC improvement and optimization.

Evan

Evan McClanahan wrote:
> So, I was working on converting a suite of GC benchmarks from C++ and scheme (dunno how long that will take, but it's the best one that I can find...) and I have some gripes.  It seems that I can never be sure which GC I'm running. A test that supposedly only takes about 8 secs on a similarly spec'd computer to mine, takes *50* secs in D on my machine.  I'm assuming that this is because I'm running the debug GC? (even after rebuilding phobos.)  It would be nice to have some better systems in place for switching between debug and release phobos.libs. Also, GC stats just don't work on my system at the moment.  Despited being declared in a similar manner to enable and disable, the linker throws this error:

Give us an idea of what the test is doing.

> gcbench.obj(gcbench)
>  Error 42: Symbol Undefined _Dgc_getStats_FS10gc_GCStatsZv
> --- errorlevel 1

It's a long-standing bug in gc.d.  I've been meaning to report it.  The GCStats struct is being defined internally in gc2.gcx, so it's causing the wrong name mangling to occur in the exported name.

If you like evil, you could probably do:

    extern (C) void Dgc_getStats_FS10gcx_GCStatsZv (GCStats *);
    alias Dgc_getStats_FS10gcx_GCStatsZv gc_getStats;

> I'm worried about the GC slowness, but I'm not sure whether or not it's a problem with me linking the debug GC or what.  Hopefully, getting a good suite of tests working will be a start on a good framework for GC improvement and optimization.

The GC speed will go through a toggle sometime, as they should be using type-based scanning.  Depending upon the application (3D apps would be most hit), that could mean scanning a thousandth the data of before.  I can't speculate on how much of a jump that'll be, but it would be very odd if it were smaller than that achievable by optimisations.

Burton Radons wrote:
> Evan McClanahan wrote:
> 
>> So, I was working on converting a suite of GC benchmarks from C++ and scheme (dunno how long that will take, but it's the best one that I can find...) and I have some gripes.  It seems that I can never be sure which GC I'm running. A test that supposedly only takes about 8 secs on a similarly spec'd computer to mine, takes *50* secs in D on my machine.  I'm assuming that this is because I'm running the debug GC? (even after rebuilding phobos.)  It would be nice to have some better systems in place for switching between debug and release phobos.libs. Also, GC stats just don't work on my system at the moment.  Despited being declared in a similar manner to enable and disable, the linker throws this error:
> 
> Give us an idea of what the test is doing.

recursive tree allocations, dumping a bunch of stuff on the heap.  It's not a great benchmark, but it's just a start.  I'm going to be translating, if possible, someone else's whole suite of GC benchmarks, so that we can have a stable way to at least get a good idea of where performance stands when different modifications are tried.


>> gcbench.obj(gcbench)
>>  Error 42: Symbol Undefined _Dgc_getStats_FS10gc_GCStatsZv
>> --- errorlevel 1
> 
> 
> It's a long-standing bug in gc.d.  I've been meaning to report it.  The GCStats struct is being defined internally in gc2.gcx, so it's causing the wrong name mangling to occur in the exported name.
> 
> If you like evil, you could probably do:
> 
>     extern (C) void Dgc_getStats_FS10gcx_GCStatsZv (GCStats *);
>     alias Dgc_getStats_FS10gcx_GCStatsZv gc_getStats;

OK.  Glad to know that I'm not the only person having that problem. When and if we fix something like this, who gets the patch?  You, Walter, Pavel?  Who's in charge of Phobos at the moment?

>> I'm worried about the GC slowness, but I'm not sure whether or not it's a problem with me linking the debug GC or what.  Hopefully, getting a good suite of tests working will be a start on a good framework for GC improvement and optimization.
> 
> The GC speed will go through a toggle sometime, as they should be using type-based scanning.  Depending upon the application (3D apps would be most hit), that could mean scanning a thousandth the data of before.  I can't speculate on how much of a jump that'll be, but it would be very odd if it were smaller than that achievable by optimisations.

That sounds good but I'm not 100% sure what exactly you're talking about.  I guess that I should spend some more time with the GC code figuring out what exactly is going on there.  I'm assuming that for the moment that the GC is scanning the entire stack and heap looking things that look like object references and pointers, without any idea of what type the values are?  How does one go about providing the type information to the GC?

Evan

"Evan McClanahan" <evan@dontSPAMaltarinteractive.com> wrote in message news:ar86i9$gov$1@digitaldaemon.com...
> recursive tree allocations, dumping a bunch of stuff on the heap.  It's not a great benchmark, but it's just a start.  I'm going to be translating, if possible, someone else's whole suite of GC benchmarks, so that we can have a stable way to at least get a good idea of where performance stands when different modifications are tried.

Such would also be useful as a testing tool.

> OK.  Glad to know that I'm not the only person having that problem. When and if we fix something like this, who gets the patch?  You, Walter, Pavel?  Who's in charge of Phobos at the moment?

It's already fixed and posted.

> I'm assuming that for the
> moment that the GC is scanning the entire stack and heap looking things
> that look like object references and pointers, without any idea of what
> type the values are?

Correct.

> How does one go about providing the type
> information to the GC?

Extending the ClassInfo data is my intention.