public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* A quick summary of gcc compilation speed from a political point of view
@ 2004-01-20 10:04 Marc Espie
  2004-01-20 12:05 ` Giovanni Bajo
  2004-01-20 13:55 ` Jan Hubicka
  0 siblings, 2 replies; 15+ messages in thread
From: Marc Espie @ 2004-01-20 10:04 UTC (permalink / raw)
  To: gcc

From the little discussion that I inadvertently started, I believe I can
start to draw conclusions.

There is a large number of people who apparently do not care at all that
gcc is getting slower, because they say that we can buy faster hardware,
and gcc is not getting slower THAT fast.

If that's the consensus, it would be a good idea to seriously amend the
GCC description.

Because I don't think GCC fits its former description.

If that's true, and speed doesn't count that much, then GCC has become
a compiler that can should only be hosted on ix86 systems.

All over systems are either becoming too expensive or too slow for almost
anyone... Frankly, I don't really see myself getting a distcc farm of
sparc64 machines in the future...

So, the target audience of GCC consists of:
- people who want native ix86 compilers that create good code;
- people who want a cross-compiler for another system that's hosted on an
ix86.


Other combinations don't look reasonable to me.   In any case, when I
pointed out other combinations that looked useful and that would be nice to
have, I completely got shooted down by various people, stating cost issues,
or the excellence of GCC as a cross-compiler.

[ From personal experience, I can tell you that cross-compiling an entire
distribution is hard, and yields a whole other set of bugs to fix.
I can also tell you that native compiling the same distribution on a little
used system will invariably expose bugs that are not visible in a
cross-compiling setting. ]


But that's not the point.

The point is that, right now, GCC is each day becoming more unusable as a
compiler on any host that isn't ix86.


-- 
	Marc

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: A quick summary of gcc compilation speed from a political point of view
@ 2004-01-20 16:07 Benjamin Kosnik
  0 siblings, 0 replies; 15+ messages in thread
From: Benjamin Kosnik @ 2004-01-20 16:07 UTC (permalink / raw)
  To: gcc; +Cc: espie

> So parhaps you can work with GGC developers on providing better
> development tools for that or provide some good way to measure
> compilation speed (SPEC tests do have compilation time graphs but they
> are not too usefull as they are with checking enabled and SPECs are too
> small to make changes visible in the noise). Or you can find some other
> way to contribute to GCC.

You know, I strongly agree with this. One of the big problems with the
speed issue is that it's so invisible: every time there is a new
release, somebody invariably complains it's slower than the last release.

Until then, nobody seems to notice, even though there are ostensibly
minimal speed requirements in the release criteria.

What's really needed is some kind of regular posting to gcc-testresults
that indicate the time it took to do a make check, or the time it took
to compile some known sources, etc. Perhaps contrib/test_summary could
be modified to do something like report the time to run make check?

If we had this, then people would have an easier time pinpointing
slowdowns. Also, the developers would be able to see exactly what
compilation performance was for various platforms, which would be an
excellent starting point.

Personally, I always run 

time make check

Just to make sure that PCH is not broken. But, I digress.

-benjamin

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: A quick summary of gcc compilation speed from a political point of view
@ 2004-01-20 20:09 Nathanael Nerode
  0 siblings, 0 replies; 15+ messages in thread
From: Nathanael Nerode @ 2004-01-20 20:09 UTC (permalink / raw)
  To: espie, gcc

Marc Espie wrote:
>Most of my work on GCC happens in other places. If you want to find
>significant work, look into the OpenBSD repository.  I've spent a long
>time catching up with recent GCC development.  One good thing is that,
>these days, GCC compiles reasonably well on OpenBSD. This was not the
>case three years ago. I also finally have enough room on my development
>machine to be able to work with GCC current.
>
>And so, I'm working on fixing things.  

Great!

Any progress on porting that configuration patch to mainline, and addressing
the various questions I asked about the config.gcc entries?  Conceptually
separate pieces of it can be submitted piecemeal as it gets ready; so, for
instance, the libc_r/libpthread bit as one change; any fixincludes issues
as another; etc.  (That's actually preferable, in fact, since it's easier
to review, and problems in one part don't necessarily hold up other parts.)

As a configury maintainer, I would really like GCC to configure correctly
for OpenBSD out of the box, so I appreciate this work.

-- 
Nathanael Nerode  <neroden at gcc.gnu.org>
http://home.twcny.rr.com/nerode/neroden/fdl.html

^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2004-01-21 11:12 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-20 10:04 A quick summary of gcc compilation speed from a political point of view Marc Espie
2004-01-20 12:05 ` Giovanni Bajo
2004-01-20 13:38   ` Gabriel Dos Reis
2004-01-20 13:51     ` Giovanni Bajo
2004-01-20 14:07       ` Gabriel Dos Reis
2004-01-20 14:22         ` Giovanni Bajo
2004-01-20 16:54           ` Gabriel Dos Reis
2004-01-20 13:59     ` Marc Espie
2004-01-20 22:01   ` Marc Espie
2004-01-21 11:15     ` Zack Weinberg
2004-01-20 13:55 ` Jan Hubicka
2004-01-20 13:59   ` Jan Hubicka
2004-01-20 16:54   ` Diego Novillo
2004-01-20 16:07 Benjamin Kosnik
2004-01-20 20:09 Nathanael Nerode

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).