Re: GCC 3.3, GCC 3.4

[Bernd Jendrissek <berndj at prism dot co dot za>]

On Thu, Jan 30, 2003 at 10:29:13PM +0100, Michael Matz wrote:
> On Thu, 30 Jan 2003, Michael S.Zick wrote:
> > > where the real problems lie), the new GC default is going to reduce or
> > > eliminate the impact of that improvement, an impact that would have been
> > > noticeable had the GC defaults not been changed, and the improvement
> > > is less likely to happen.
> > >
> > So, lets make part of the testing protocal: "disable GC"
> 
> What can be disabled easily is collecting and reclaiming GC memory.  What
> can _not_ be done easily is to go back to a memory management like in
> 2.95.x or earlier.  But that would be needed to really calculate the cost
> of GC, because collecting is only a part of the overhead.  The other part
> comes from different layout of memory, and the resulting slowness is
> distributed all over the compiler (so is not even measurable in one single
> function suddenly taking much more time).  To this end we can't simply
> "disable" GC.  One would need to rewrite the allocators too, but then have
> the problem that noone is freeing memory explicitely anymore, which would
> again be different to 2.95.x.

Could one hack valgrind to have adjustable memory latencies?  Surely...

AFAICT the problem here is that GC bloats memory structures, which causes
the cache hit rates to drop.  (Is raw memory bandwidth an issue here?)  The
cache hit rate drops because fewer objects in GCC's "working set" fit into
the small cache.  So, couldn't valgrind "compensate" for the effectively
smaller cache lines by pretending them to be, say, 48 bytes.  Or maybe
something more dynamic based on hints from a hacked GC allocator?

Grr, I wish I could make more sense, but I'm out of my depth...

Bernd Jendrissek