This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.3, GCC 3.4
- From: Mike Stump <mstump at apple dot com>
- To: Neil Booth <neil at daikokuya dot co dot uk>
- Cc: Mike Stump <mrs at apple dot com>, Benjamin Kosnik <bkoz at redhat dot com>, gcc at gcc dot gnu dot org
- Date: Thu, 30 Jan 2003 16:13:05 -0800
- Subject: Re: GCC 3.3, GCC 3.4
On Thursday, January 30, 2003, at 03:38 PM, Neil Booth wrote:
I'm interested in improving the quality of GCC. Your statment above
indicates you're interested in pointing to a number and saying "look,
it's lower", regardless of what that means long-term. Hell, let's
not free anything at all and turn GC off altogether; GCC would be
faster
for 90% of files I imagine.
Guess what? For smaller programs, it already does that! So, you are
just describing status quo.
The improvements you're justifying are short-term gratification, but
make the genuine
improvements harder to develop, hard to find, and less easy to justify.
I don't think that's a good thing for the project long-term.
Does this mean that we should immediately change the 8MB to 0MB?
What I _am_ saying is, pretend the 8MB wasn't there. I want you to
come up with the right number, the best number, the number you can say,
this is the right number and I like it. Don't peek at what it was
before, that is cheating. Tell me, what is the best number, and why?
This is a serious question. Please support your number, so that we
know that it wasn't just a wild ass guess, as certainly, we are better
than that.
Each magic constant needs to be defended and tweaked from time to time,
that is just the nature of magic constants. I do agree with you, that
it is better to not have magic constants, it is better to have well
thought out algorithms in the compiler that don't need magic constants,
but I'm pragmatic on this point I guess. Look at all the magic
constants in the code already, it is littered with them. I don't think
I've seen a compelling existence proof that it _is_ possible to get rid
of them.
I don't think we should disallow fixing of broken magic constants, just
because it might be possible to write the code without them. If we can
find a better magic constant, and get a 25% speed improvement, why
should we sacrifice the improvement?
If we must make the compiler perform worse to try and trick someone
into substantially improving it, why is 100KB not a better magic
constant than 8MB? Surely that would cause more pain than the current
number?