On 6/7/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 6/7/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> Hello,
>
> > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> >
> > > Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> > >
> > > > The problem is, that it does not give any speedups (it is almost
> > > > completely compile-time neutral for compilation of preprocessed
> > > > gcc sources). I will check whether moving also edges to pools
> > > > changes anything, but so far it does not seem very promising :-(
> > >
> > > Does it make any difference for gcc.c-torture/compile/20001226-1.c?
> > > And of course it won't make any difference if you have enough memory
> > > that you never need to garbage collect without your patch.
> >
> > I was wrong to say that. It could make a difference even if you don't
> > garbage collect, since the allocation will be cheaper. But that is
> > likely to be a relatively small effect.
>
> actually, the expected speedup was mostly supposed to come from better
> locality. The speed of garbage collection should be about unchanged.
> Regarding the speed of allocation, pool_alloc might be slightly faster,
> but probably not significantly.
Uh, structures as big as basic_block won't get better locality by placing
them near each other. But maybe I'm missing something ;)
They did when we took a couple percent slowdown from moving them to
GC. See the patch that did it :)
Though i think they were smaller then :)
Edges were also pool alloc'd, and i believe both were switched at the
same time, so it's possible the locality came from the edges.
