• Evan McClanahan <evan dontSPAMaltarinteractive.com> Nov 16 2002
• Burton Radons <loth users.sourceforge.net> Nov 16 2002
• Evan McClanahan <evan dontSPAMaltarinteractive.com> Nov 17 2002
• "Walter" <walter digitalmars.com> Nov 20 2002

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.