This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 3.3, GCC 3.4


Benjamin Kosnik <bkoz@redhat.com> writes:

> >> we're not really getting any faster.
> >
> >Yes, it really is faster.  It really is better.  Consider for example 
> >that we had the value be 2KB, and 1% increase, and someone said bumping 
> >it up to 30% and 8MB is wrong and just papers over the real problem.  
> >We'd laugh at them, just the same way I laugh at you now.
> 
> You know, I agree with you. I could not figure out why Neil was saying
> this, when I posted real timing numbers, based on increased numbers, and
> others backed me up. 
> 
> It seems as if the defaults were set arbitrarily: testing with various
> numbers tells me that bumping up to 16MB gets the maximum bang for the
> minimum setting.
> 
> Holding on to these poorly picked initial numbers, in the face of data
> that suggests a better set of number, seems to be incredibly foolish.

It's not the case that there's one number for this parameter that is
great for everyone.  The current number is acceptable on small-memory
machines but not optimal for larger machines.  A larger number would
be better for larger machines, but would cause small-memory machines
to be unusable.

In this context, of course, 'large-memory' means simply that there's
lots of memory available now.  Start a mozilla running and suddenly
you might find you're running on a small-memory machine :-).  That's
why I want to make this parameter adjust at runtime.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]