Re: gcc and compiling speed

Re: gcc and compiling speed

[Vincent Diepeveen]

At 21:05 29-2-2004 -0700, Theo de Raadt wrote:
>> Sure, as long as you do timing tests and put it in bugzilla when you do
>> it. If you can narrow down classes of slow testcases then you'll be
>> helping as opposed to adding to the noise which you are currently doing.
>
>Eric,

>On the box where you are right now, what is the speed difference
>between gcc2 compiling your kernel, versus gcc3 compiling your kernel.

>Since I can bet gcc3 is slower for you, have you submitted detailed
>test results for that?
>
>Frankly, as consumers of your compiler we don't have a clue how to
>start submitting results like you are suggesting we do.  Clearly it is
>not about test cases when we can't find anything faster!
>
>We just see one point of analysis: This new compiler is even more of a
>slug than the previous one.

IMHO the improved quality GCC delivers which will execute the code faster
is more important than the slowdown. The slower compiling speed is always
less of a concern considering the processors having become that faster.

I remember all those old GCC 2.xx snapshots crashing one after each other
at difficult code. Specint2004 still showed some problems with some code i
wrote at different compilers, not with latest gcc's though!

Yet all 2.xx versions starved from problems. All that improved. Improvement
means usually more complexity and that eats cycles.

Nevertheless lossless speeding up compile time is always good.

>But if you want, keep on ignoring what we point out... I'm sure Redhat
>keeps buying you faster machines...

Just buy a dual opteron and let it profile with 2 cpu's simultaneously with
16 registers!

That will speed it up quite some!

btw At multiprocessor BSD machines, does gcc get run using all processors
there instead of running all threads at 1 processor? If not, i know
something to speed you up quite some...

Re: gcc and compiling speed

[John S. Dyson]

> 
> btw At multiprocessor BSD machines, does gcc get run using all processors
> there instead of running all threads at 1 processor? If not, i know
> something to speed you up quite some...
> 
FreeBSD has a couple of multi-threading libs, and at least one
of them allows for multi-cpu threading.  Frankly, I don't keep
up with the official release versions, but I often use the
multi-cpu threading libs.

John

Re: gcc and compiling speed

[Zack Weinberg]

"John S. Dyson" <toor@y.jdyson.com> writes:

>> 
>> btw At multiprocessor BSD machines, does gcc get run using all processors
>> there instead of running all threads at 1 processor? If not, i know
>> something to speed you up quite some...
>> 
> FreeBSD has a couple of multi-threading libs, and at least one
> of them allows for multi-cpu threading.  Frankly, I don't keep
> up with the official release versions, but I often use the
> multi-cpu threading libs.

GCC itself is single threaded, but Make has the wonderful -j option
which lets you parallelize entire builds.

zw

gcc and compiling speed

[Andrew Pinski]

Marc,
Now I know you have been asked before every time you bring up on the
GCC's mailing list about a set of preprocessed source for openbsd so
that the speed of GCC will improve.  It seems like you are ignoring
them and still complain about the compile time speed regressions in
GCC.  If you (or some from the openbsd project) submit a bug with
numbers and a way to reproduce it with say the openbsd's kernel
sources, we will no longer disagree with you and fix the problem
in GCC.

Thanks,
Andrew Pinski
a gcc bug master and libobjc maintainer

Re: gcc and compiling speed

[Theo de Raadt]

> Marc,
> Now I know you have been asked before every time you bring up on the
> GCC's mailing list about a set of preprocessed source for openbsd so
> that the speed of GCC will improve.

How will this improve the speed of gcc?

Are pre-processed headers the way that gcc3 is going to recover
the speed that it has lost?

> It seems like you are ignoring
> them and still complain about the compile time speed regressions in
> GCC.

And I well think that he should.  I've been watching this from the
side lines.  I am just flabbergasted at how we keep being told that
gcc will become faster, yet every release, it is in fact slower.  Can
someone inside the compiler group please... PLEASE... make it a
mandate that noone will ever again make such a promise?

Because there has *never* been a gcc that compiled code faster than
the previous release did.

> If you (or some from the openbsd project) submit a bug with
> numbers and a way to reproduce it with say the openbsd's kernel
> sources, we will no longer disagree with you and fix the problem
> in GCC.

The problem is when a ultrasparc cpu takes 40% more time to build the
source tree.  For no perceivable benefit; really.

I understand that there is a goal to make gcc produce better output
code.

But we are programmers.  We spend our lives compiling code.  When can
we get a compiler that is tuned for us?

One that does not become 2x slower in 3 years, for absolutely no
percievable benefit in performance (and the output binaries got
larger too).

Re: gcc and compiling speed

[Daniel Jacobowitz]

On Sun, Feb 29, 2004 at 07:59:28PM -0700, Theo de Raadt wrote:
> > Marc,
> > Now I know you have been asked before every time you bring up on the
> > GCC's mailing list about a set of preprocessed source for openbsd so
> > that the speed of GCC will improve.
> 
> How will this improve the speed of gcc?
> 
> Are pre-processed headers the way that gcc3 is going to recover
> the speed that it has lost?

I found pretty Andrew's request very confusingly worded (sorry
Andrew!), so let me rephrase it: preprocessed (-E, -save-temps) output
for specific test cases that have slowed down.  This is what people ask
Marc for every time he reports slowdown numbers, and so far he hasn't
provided any.

Not that we're disputing that GCC has slowed down.  But without
specific testcases that have regressed, it's hard to do anything about
it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gcc and compiling speed

[Theo de Raadt]

> > > Marc,
> > > Now I know you have been asked before every time you bring up on the
> > > GCC's mailing list about a set of preprocessed source for openbsd so
> > > that the speed of GCC will improve.
> > 
> > How will this improve the speed of gcc?
> > 
> > Are pre-processed headers the way that gcc3 is going to recover
> > the speed that it has lost?
> 
> I found pretty Andrew's request very confusingly worded (sorry
> Andrew!), so let me rephrase it: preprocessed (-E, -save-temps) output
> for specific test cases that have slowed down.  This is what people ask
> Marc for every time he reports slowdown numbers, and so far he hasn't
> provided any.

Is include file parsing a time critical component of gcc?

Is it a part that has slowed down a lot?

Quite frankly, I bet that cpp performance is entirely lost in the
noise...

> Not that we're disputing that GCC has slowed down.  But without
> specific testcases that have regressed, it's hard to do anything about
> it.

Please.... an entire operating system compiles slower, on every
architecture we have tested it, and I have not heard of any case which
compiles faster (except sha1.c on sparc cpus, where gcc got into some
optimizer loop).

Re: gcc and compiling speed

[Gabriel Dos Reis]

Theo de Raadt <deraadt@cvs.openbsd.org> writes:

| > > > Marc,
| > > > Now I know you have been asked before every time you bring up on the
| > > > GCC's mailing list about a set of preprocessed source for openbsd so
| > > > that the speed of GCC will improve.
| > > 
| > > How will this improve the speed of gcc?
| > > 
| > > Are pre-processed headers the way that gcc3 is going to recover
| > > the speed that it has lost?
| > 
| > I found pretty Andrew's request very confusingly worded (sorry
| > Andrew!), so let me rephrase it: preprocessed (-E, -save-temps) output
| > for specific test cases that have slowed down.  This is what people ask
| > Marc for every time he reports slowdown numbers, and so far he hasn't
| > provided any.
| 
| Is include file parsing a time critical component of gcc?

I believe the reason people are asking for a preprocessed file is that
they wanted to have a real translation unit (i.e. minimally
self-contained) testcase they can feed their compilers with while trying
to fix the speed regression.  If you happen to have a file that is
representative enough, that would help them. 

(I assumed you're not suggesting they download the entire BSD
kernel) 

-- Gaby

Re: gcc and compiling speed

[Theo de Raadt]

> (I assumed you're not suggesting they download the entire BSD
> kernel) 

We don't believe it is restricted to just our kernel.  And we've never
really talked about kernel compile speed, instead we measure "make
build" time, that meaning the compilation of the full system --
kernel, bootblocks, all the libraries, everything.  It is a giant
source tree.

A 40% slowdown from just changing compilers ... how do you explain
that?  I explain it by saying the compiler builds the entire system
40% slower.

More than that, we think everything compiles slower, on all
architectures.  There is some variance; some systems slow down more
than others.

And thus far, there's been no real evidence contrary.

Perhaps the gcc people are sticking to microbenchmarks?

We don't know.  But they keep asking for micro-test reports... Why
don't they compare themselves to see how much slower it is.  For
the best impact, I recommend using a sparc64.  But an i386 or powerpc
will show it too.

Re: gcc and compiling speed

[Daniel Berlin]

>
> We don't believe it is restricted to just our kernel.  And we've never
> really talked about kernel compile speed, instead we measure "make
> build" time, that meaning the compilation of the full system --
> kernel, bootblocks, all the libraries, everything.  It is a giant
> source tree.

Right, so why don't you kindly do us a favor, and profile a run of gcc 
over the entire source tree, and tell us what the top functions are, 
since you don't think it's useful to preprocess pieces of source that 
have significantly slowed down, and send them to us so we can reproduce 
and fix it.

>
> A 40% slowdown from just changing compilers ... how do you explain
> that?  I explain it by saying the compiler builds the entire system
> 40% slower.
>

Has anyone disputed that it builds your source tree slower?
Or do you just like pointing it out?

> More than that, we think everything compiles slower, on all
> architectures.  There is some variance; some systems slow down more
> than others.
>

> And thus far, there's been no real evidence contrary.

For your source tree, this is true.
This is also because nobody from OpenBSD provides us with anything 
other than whining.  We ask for preprocessed sources. Nobody provides 
it.

Note that when someone like Gerald provides us with preprocessed C++ 
sources of his app that used to compile fast, and then compiled slow 
and took lots of memory, people spent significant amounts of time 
reducing the memory usage and compile time of his application

See http://gcc.gnu.org/ml/gcc/2004-01/msg01255.html for a show that 3.4 
is faster at compiling the linux kernel than 3.2 is.
Maybe you too have forgotten to disable checking.
If not, we need profiles or code that we can use to reproduce it.
>
> Perhaps the gcc people are sticking to microbenchmarks?
>
No.
Kindly explain how you expect people without access to openbsd 
machines, to profile and find the cause of the slowdowns, without, you 
know, specific examples or preprocessed source or function profiles?

> We don't know.  But they keep asking for micro-test reports... Why
> don't they compare themselves to see how much slower it is.
Because it's worthless to suggest that everyone go download a copy of 
openbsd and use it, just to see how much slower it is?
  Did i mention that no one is likely to do this?
If you want people to track down why it's slower, we need concrete 
examples of code that has slowed down in compilation speed.
Yes, we need micro-tests.  GCC is made up of many thousands of pieces 
of code.  Do you honestly think there is some single piece of code 
responsible for a 40% slowdown?  We need code that compiled fast, and 
doesn't compile fast now, so that we can attempt to fix the problem.
If you aren't willing to provide this,  at the very least we would need 
profiles showing what functions are using up most of gcc's time while 
compiling your source tree, for both gcc <old version> and gcc <new 
version>

> For
> the best impact, I recommend using a sparc64.  But an i386 or powerpc
> will show it too.
>
Nobody is going to take you up on this offer.

Re: gcc and compiling speed

[Gerald Pfeifer]

On Sun, 29 Feb 2004, Daniel Berlin wrote:
> Note that when someone like Gerald provides us with preprocessed C++
> sources of his app that used to compile fast, and then compiled slow
> and took lots of memory, people spent significant amounts of time
> reducing the memory usage and compile time of his application

Indeed, Theo, you should _really_ give it a try and make a self-contained
report.

As an example, below are some of the changes made to GCC in response to
me providing a testcase:

  http://gcc.gnu.org/ml/gcc-patches/2004-01/msg00892.html
  http://gcc.gnu.org/ml/gcc-patches/2004-01/msg00905.html
  http://gcc.gnu.org/ml/gcc/2004-01/msg00670.html
  http://gcc.gnu.org/ml/gcc-patches/2004-01/msg00886.html
  http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01539.html
  http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01630.html
  http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01880.html
  http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02038.html
  http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02055.html
  http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02072.html
  http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02211.html
  http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02279.html
  http://gcc.gnu.org/ml/gcc/2004-01/msg01788.html
  http://gcc.gnu.org/ml/gcc-patches/2004-01/msg03041.html
  http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01930.html
  http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01979.html

Gerald
-- 
Gerald Pfeifer (Jerry)   gerald@pfeifer.com   http://www.pfeifer.com/gerald/

Re: gcc and compiling speed

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

Theo de Raadt <deraadt@cvs.openbsd.org> writes:

>> (I assumed you're not suggesting they download the entire BSD
>> kernel) 
>
> We don't believe it is restricted to just our kernel.  And we've never
> really talked about kernel compile speed, instead we measure "make
> build" time, that meaning the compilation of the full system --
> kernel, bootblocks, all the libraries, everything.  It is a giant
> source tree.
>
> A 40% slowdown from just changing compilers ... how do you explain
> that?  I explain it by saying the compiler builds the entire system
> 40% slower.
>
> More than that, we think everything compiles slower, on all
> architectures.  There is some variance; some systems slow down more
> than others.

Just give us as a start a single file that the current GCC compiles so
much slower together with the numbers.  Since we do not have access to
OpenBSD, we need that file self contained, meaning preprocessed with
headers.  Others have explained how to do that.

Then file a bug report in bugzilla and answer to this email telling us
what bugzilla number it is.

The same procedure has been done by other folks where they saw a slow
compiler and they have taken the worst example and GCC developers have
started tuning.  But without even *one* single example test case,
there's nothing we can do...

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: gcc and compiling speed

[Peter Galbavy]

Andreas Jaeger wrote:
> much slower together with the numbers.  Since we do not have access to
> OpenBSD, we need that file self contained, meaning preprocessed with

Cough. ftp://ftp.openbsd.org/pub/OpenBSD/

Peter

Re: gcc and compiling speed

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

"Peter Galbavy" <peter.galbavy@knowtion.net> writes:

> Andreas Jaeger wrote:
>> much slower together with the numbers.  Since we do not have access to
>> OpenBSD, we need that file self contained, meaning preprocessed with
>
> Cough. ftp://ftp.openbsd.org/pub/OpenBSD/

To make myself clear: Most (all?) of us do not have access to a system
running OpenBSD where we can test this ourselves, so we need the
preprocessed source.

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: gcc and compiling speed

[Peter Galbavy]

Andreas Jaeger wrote:
> "Peter Galbavy" <peter.galbavy@knowtion.net> writes:
>
>> Andreas Jaeger wrote:
>>> much slower together with the numbers.  Since we do not have access
>>> to OpenBSD, we need that file self contained, meaning preprocessed
>>> with
>>
>> Cough. ftp://ftp.openbsd.org/pub/OpenBSD/
>
> To make myself clear: Most (all?) of us do not have access to a system
> running OpenBSD where we can test this ourselves, so we need the
> preprocessed source.

I will provide a sacrificial system (i386 only ATM), with root (over ssh
with keys) to anyone who asks nicely - and is not an idiot. Or I will in
about 2 days after a rebuild of some kit.

Peter

Re: gcc and compiling speed

[William Ahern]

On Mon, Mar 01, 2004 at 08:05:10PM -0000, Peter Galbavy wrote:
> Andreas Jaeger wrote:
> > "Peter Galbavy" <peter.galbavy@knowtion.net> writes:
> >
> >> Andreas Jaeger wrote:
> >>> much slower together with the numbers.  Since we do not have access
> >>> to OpenBSD, we need that file self contained, meaning preprocessed
> >>> with
> >>
> >> Cough. ftp://ftp.openbsd.org/pub/OpenBSD/
> >
> > To make myself clear: Most (all?) of us do not have access to a system
> > running OpenBSD where we can test this ourselves, so we need the
> > preprocessed source.
> 
> I will provide a sacrificial system (i386 only ATM), with root (over ssh
> with keys) to anyone who asks nicely - and is not an idiot. Or I will in
> about 2 days after a rebuild of some kit.
> 
> Peter

Anybody who could use shell access--to benefit free software--on my
OpenBSD/Alpha system just let me know. No root, though.

- Bill

Re: gcc and compiling speed

[Zack Weinberg]

Theo de Raadt <deraadt@cvs.openbsd.org> writes:

>> Marc,
>> Now I know you have been asked before every time you bring up on the
>> GCC's mailing list about a set of preprocessed source for openbsd so
>> that the speed of GCC will improve.
>
> How will this improve the speed of gcc?

If Marc (or anyone) provides us with a test case for the performance
regression - for instance, the set of files produced by running gcc -E
over all of the openbsd kernel, which is what Andrew meant - then we
can find out why the compiler is slower, and fix it.

We do have our own test cases for compile time, and they have been
being fixed (mostly by Jan Hubicka) but we don't know that this will
help you.

zw

Re: gcc and compiling speed

[Theo de Raadt]

> Theo de Raadt <deraadt@cvs.openbsd.org> writes:
> 
> >> Marc,
> >> Now I know you have been asked before every time you bring up on the
> >> GCC's mailing list about a set of preprocessed source for openbsd so
> >> that the speed of GCC will improve.
> >
> > How will this improve the speed of gcc?
> 
> If Marc (or anyone) provides us with a test case for the performance
> regression - for instance, the set of files produced by running gcc -E
> over all of the openbsd kernel, which is what Andrew meant - then we
> can find out why the compiler is slower, and fix it.
> 
> We do have our own test cases for compile time, and they have been
> being fixed (mostly by Jan Hubicka) but we don't know that this will
> help you.

How big is your mailbox?

I can compile the entire source tree for OpenBSD and mail you
gcc -E output for every file.

I can then do that on 4 architectures.

That might be a bit large for you.  Or you can simply take pretty
much any source code off the net and do your own performance test
with:

	/bin/time make

That is the performance test that matters.  Does gcc3 compile
mozilla faster on any machine, than gcc2 did?

Re: gcc and compiling speed

[Eric Christopher]

> 
> How big is your mailbox?
> 
> I can compile the entire source tree for OpenBSD and mail you
> gcc -E output for every file.

Sure, as long as you do timing tests and put it in bugzilla when you do
it. If you can narrow down classes of slow testcases then you'll be
helping as opposed to adding to the noise which you are currently doing.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: gcc and compiling speed

[Theo de Raadt]

> Sure, as long as you do timing tests and put it in bugzilla when you do
> it. If you can narrow down classes of slow testcases then you'll be
> helping as opposed to adding to the noise which you are currently doing.

Eric,

On the box where you are right now, what is the speed difference
between gcc2 compiling your kernel, versus gcc3 compiling your kernel.

Since I can bet gcc3 is slower for you, have you submitted detailed
test results for that?

Frankly, as consumers of your compiler we don't have a clue how to
start submitting results like you are suggesting we do.  Clearly it is
not about test cases when we can't find anything faster!

We just see one point of analysis: This new compiler is even more of a
slug than the previous one.

But if you want, keep on ignoring what we point out... I'm sure Redhat
keeps buying you faster machines...

Re: gcc and compiling speed

[Eric Christopher]

> On the box where you are right now, what is the speed difference
> between gcc2 compiling your kernel, versus gcc3 compiling your kernel.
> 
> Since I can bet gcc3 is slower for you, have you submitted detailed
> test results for that?
> 

No, because I don't care on the box I'm on. I have other cares, code
quality and size mainly, for a different target (mips).

> Frankly, as consumers of your compiler we don't have a clue how to
> start submitting results like you are suggesting we do.  Clearly it is
> not about test cases when we can't find anything faster!
> 

Marc has been told many times how to do so. Many people have asked and
been told and submitted bugs on specific slowdowns that they want
addressed. Everyone seems to be able to understand this - except you.
You don't have a reputation for being particularly dense.

I'll give you the same directions other people in this thread have given
you though:

1) find a file that is compiling slower.
2) use -save-temps on the compile line and recompile it.
3) attach the resultant .i (or .ii if c++) to a bugzilla case that you
file at http://gcc.gnu.org/bugzilla/


> But if you want, keep on ignoring what we point out... I'm sure Redhat
> keeps buying you faster machines...

Actually, they don't, but it's not an important argument - we get
complaints from people using machines that are much faster than mine. 

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: gcc and compiling speed

[Gabriel Dos Reis]

Theo de Raadt <deraadt@cvs.openbsd.org> writes:

| > Theo de Raadt <deraadt@cvs.openbsd.org> writes:
| > 
| > >> Marc,
| > >> Now I know you have been asked before every time you bring up on the
| > >> GCC's mailing list about a set of preprocessed source for openbsd so
| > >> that the speed of GCC will improve.
| > >
| > > How will this improve the speed of gcc?
| > 
| > If Marc (or anyone) provides us with a test case for the performance
| > regression - for instance, the set of files produced by running gcc -E
| > over all of the openbsd kernel, which is what Andrew meant - then we
| > can find out why the compiler is slower, and fix it.
| > 
| > We do have our own test cases for compile time, and they have been
| > being fixed (mostly by Jan Hubicka) but we don't know that this will
| > help you.
| 
| How big is your mailbox?

Well, there is a central database for GCC

      http://gcc.gnu.org/bugzilla/

that saves people from getting huge testcases directly in their
mailboxes. 

I have no idea how large is GCC's bugzilla  harddrive though


-- Gaby

Re: gcc and compiling speed

[Zack Weinberg]

Theo de Raadt <deraadt@cvs.openbsd.org> writes:

>> Theo de Raadt <deraadt@cvs.openbsd.org> writes:
>> 
>> >> Marc,
>> >> Now I know you have been asked before every time you bring up on the
>> >> GCC's mailing list about a set of preprocessed source for openbsd so
>> >> that the speed of GCC will improve.
>> >
>> > How will this improve the speed of gcc?
>> 
>> If Marc (or anyone) provides us with a test case for the performance
>> regression - for instance, the set of files produced by running gcc -E
>> over all of the openbsd kernel, which is what Andrew meant - then we
>> can find out why the compiler is slower, and fix it.
>> 
>> We do have our own test cases for compile time, and they have been
>> being fixed (mostly by Jan Hubicka) but we don't know that this will
>> help you.
>
> How big is your mailbox?
>
> I can compile the entire source tree for OpenBSD and mail you
> gcc -E output for every file.

Ideally you would create a .tar.bz2 of all the .i files and put them
on a web or FTP site.

We do *NOT* want performance numbers to go with these tarfiles, we
just want the raw preprocessed source, and only using one reference
compiler.

> I can then do that on 4 architectures.

Is there that much code that varies per architecture?  

> That is the performance test that matters.  Does gcc3 compile
> mozilla faster on any machine, than gcc2 did?

What you don't realize, perhaps, is just how data-driven gcc (any
version) is.  I could spend weeks tuning gcc to work well on mozilla
and it could make no. difference. whatsoever. to how long it takes to
compile OpenBSD core.

zw

Re: gcc and compiling speed

[Zack Weinberg]

Marc Espie <espie@nerim.net> writes:

>> What you don't realize, perhaps, is just how data-driven gcc (any
>> version) is.  I could spend weeks tuning gcc to work well on mozilla
>> and it could make no. difference. whatsoever. to how long it takes to
>> compile OpenBSD core.

Thank you.

> I'm just busy with various things, including an upcoming OpenBSD release,
> and a move between apartments, but I'll provide this preprocessed source
> as soon as it gets on the top list of my things to do.
>
> On the other hand, what you're saying is plain bullshit, Zack. The slowdown
> of gcc3 vs. gcc2 is NOT dependent on the set of source files.

You misunderstand.  I do not deny that gcc 3.3 is slower than gcc 2.95
for almost all C input (*please* be specific about minor version
numbers - 3.0, 3.[12], 3.3, 3.4, and mainline are all very different
beasts).  I have observed the slowdown myself, in fact.

What I said was that speeding up GCC for one set of source files is
unlikely to speed it up for another.  This is *also* true.  And this
is why we keep asking you for your test cases.

(If we get *enough* test cases, we can cover all the code paths and
speed the compiler up in general, but we aren't there yet.)

zw

Re: gcc and compiling speed

[Steven Bosscher]

On Monday 01 March 2004 03:59, Theo de Raadt wrote:
> > If you (or some from the openbsd project) submit a bug with
> > numbers and a way to reproduce it with say the openbsd's kernel
> > sources, we will no longer disagree with you and fix the problem
> > in GCC.
>
> The problem is when a ultrasparc cpu takes 40% more time to build the
> source tree.  For no perceivable benefit; really.

I suppose you're right about most gcc3 releases, yes they're slower
than 2.95.3. This is a known issue and for gcc 3.4 we're trying harder
again to make it faster than previous gcc3 releases.  All I have seen
from OpenBSD to help out with this is occasional bashing of gcc, but
no test cases or performance tracking on a regular basis.

> I understand that there is a goal to make gcc produce better output
> code.
>
> But we are programmers.  We spend our lives compiling code.  When can
> we get a compiler that is tuned for us?

What about better diagnostics, correctness, reliability, other things
that have improved significantly since gcc2, in areas that help you,
as a programmer?  You conveniently ignore them.
(Hint: turning off diagnostics will also make your compiler faster.)

> One that does not become 2x slower in 3 years, for absolutely no
> percievable benefit in performance (and the output binaries got
> larger too).

There is performance checking using SPEC benchmarks.  There are 
numbers (http://www.suse.de/~aj/SPEC/CINT/sandbox-b/SPECint_big.png)
that suggest gcc _does_ produce better code compared to >2 years
ago.  There also are numbers for the size of the binaries produced
for SPEC (http://www.suse.de/~aj/SPEC/CINT/sandbox-b/Total-size_big.png).
Finally, there is a special-purpose code-size benchmark called CSiBE
(http://sed.inf.u-szeged.hu/csibe/) that is run on a daily basis for
a number of targets.

The people maintaining these testers kick us when we have regressions.
But as you can see, the trends have been good over the past few years.

So for all we know, things are not as dramatic as OpenBSD people like
to put it.  And where things are worse than before, we need your help
to find out why and to do something about it.

Gr.
Steven


---
The USA, land of the free, hope of the brave.  Only a bit too scared now.
http://www.cbc.ca/news/background/arar/