Re: gcc 3.5 integration branch proposal

[Geoff Keating <geoffk at geoffk dot org>]

"Zack Weinberg" <zack@codesourcery.com> writes:

> Geoffrey Keating <geoffk@apple.com> writes:
> >> One cause of excessive memset that I have wanted to address for years
> >> is, make_node() clears the entire tree node - but make_node is almost
> >> always called from somewhere that's going to fill in most or all of
> >> the fields anyway.  We ought to have something like the gen_rtx_fmt_*
> >> functions for tree nodes.
> >
> > You're looking at this the wrong way.  We have to load the object into
> > cache anyway, it does not really matter if make_node does it or it's
> > done later.
> >
> > I'll emphasize Jan's comment: when you analyze GCC performance, you
> > can usually disregard all code that doesn't cause cache faults.
> 
> I think you misunderstand what I was saying, or else my testing is on
> chips with very different cache behavior.
> 
> The current effect is, make_node loads and zeroes the entire node, and
> then most fields of that are rewritten with live data.  I don't have
> numbers to say what that does for trees, but I know that cpplib used
> to do similar things to its own data structures, and changing it not
> to was good for an overall 1-2% on wall clock time running gcc -E.
> 
> Fundamentally, cutting down the write traffic even just to L1 can't be
> a bad thing.

Yes; this kind of logic is why many people waste a lot of time
optimising the wrong place in their code.  Logically, deleting
instructions means the processor has to do less work and therefore
makes the program faster.  In practise, though, a write to L1 cache
takes about 1/3 cycle, but a L2 cache miss takes ~100, and so L2 cache
misses dominate execution time.

Now, if you're cpplib, and you're zeroing a structure on the stack,
the arithmetic is different, since the stack is usually hot.  This is
not cpplib.

-- 
- Geoffrey Keating <geoffk@geoffk.org>