Re: GCC 3.3 compile speed regression - AN ANSWER

[Michael S. Zick <mszick at goquest dot com>]

On Sunday 09 February 2003 11:45 am, Marc Espie wrote:
>
> the next version is always going to be better.
>
> After a few releases, it gets really hard to believe how the next release
> is going to be better, since reality seems to prove otherwise.
>
Taking several steps back from the current problem(s) for a broader
view...

Perhaps it is the Open Source Development, Staffed by Volunteers
model that is the central point to be dealt with.

Compiler execution speed;
Adherence to standards;
Effectiveness of the code generated 
(your choice of definition of "Effectiveness");

Those are all measures of consideration to be given when selecting
a production compiler.

People volunteer for what interests them (or interests their employer).

Adding the hottest new fad in compiler science to a widely used
compiler can gather widespread interest.  
Even adding established, proven (recent) compiler techniques to 
that compiler can gather widespread interest.

There is rarely a lack of volunteers for such intellectual challenges.

Although challenging in its own way, bug fixing just doesn't have the
same intellectual appeal.

Sorting out things like a ten year accumulation of data structures into
a fast, elegant, production compiler core is just plain hard work.
Fortunately, there are a few people who like that sort of thing but there
are most certainly fewer of them in the world than of the compiler
science explorers.

GCC as a widely used, Open Source, compiler is certainly a good
vehicle for the compiler science explorers.  But where does that
leave the persons hoping it will become a "killer" of a production
compiler?

So, lets deal with that question.

Set up, right at the top of the tree, two branches.  Perhaps even
name one of them something other than GCC (pGCC?).

This new, production compiler, branch will not accept "outside"
merges.  It will evolve ONLY by "pulls" from the current GCC tree,
still maintained by the compiler science explorers in the current
fashion.

This will require some agreement on how proven a compiler change
in the GCC tree must be to qualify as "ready to pull into production";
but presuming that can be established...

How do you get people interested in volunteering for "grunt work"
such as this?

Present it as an intellectual challenge, possibly also a technical
challenge, to bring that new, well established, well proven, GCC
compiler change into pGCC without degrading any of those first
three measures of a production compiler.

That should be one source of volunteers.  
Another source of volunteers would be those "volunteered" by their 
employers.  In this case, the employers would be those whose interest 
in a solid production compiler is stronger than their interest in a 
"bleeding edge" compiler.

My suggestion:
Create two "mainline" compiler projects; the current GCC project
and a production compiler version project.

Mike