* Re: gcc and compiling speed
@ 2004-03-01 4:23 Vincent Diepeveen
2004-03-01 5:00 ` John S. Dyson
0 siblings, 1 reply; 25+ messages in thread
From: Vincent Diepeveen @ 2004-03-01 4:23 UTC (permalink / raw)
To: gcc@gcc.gnu.org List
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...
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 4:23 gcc and compiling speed Vincent Diepeveen
@ 2004-03-01 5:00 ` John S. Dyson
2004-03-01 5:31 ` Zack Weinberg
0 siblings, 1 reply; 25+ messages in thread
From: John S. Dyson @ 2004-03-01 5:00 UTC (permalink / raw)
To: Vincent Diepeveen; +Cc: gcc@gcc.gnu.org List
>
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 5:00 ` John S. Dyson
@ 2004-03-01 5:31 ` Zack Weinberg
0 siblings, 0 replies; 25+ messages in thread
From: Zack Weinberg @ 2004-03-01 5:31 UTC (permalink / raw)
To: John S. Dyson; +Cc: Vincent Diepeveen, gcc@gcc.gnu.org List
"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
^ permalink raw reply [flat|nested] 25+ messages in thread
* gcc and compiling speed
@ 2004-03-01 0:43 Andrew Pinski
2004-03-01 2:58 ` Theo de Raadt
0 siblings, 1 reply; 25+ messages in thread
From: Andrew Pinski @ 2004-03-01 0:43 UTC (permalink / raw)
To: tech, Marc Espie; +Cc: gcc@gcc.gnu.org List, 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 0:43 Andrew Pinski
@ 2004-03-01 2:58 ` Theo de Raadt
2004-03-01 3:07 ` Daniel Jacobowitz
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Theo de Raadt @ 2004-03-01 2:58 UTC (permalink / raw)
To: Andrew Pinski; +Cc: tech, Marc Espie, gcc@gcc.gnu.org List
> 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).
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 2:58 ` Theo de Raadt
@ 2004-03-01 3:07 ` Daniel Jacobowitz
2004-03-01 3:46 ` Theo de Raadt
2004-03-01 3:10 ` Zack Weinberg
2004-03-01 8:09 ` Steven Bosscher
2 siblings, 1 reply; 25+ messages in thread
From: Daniel Jacobowitz @ 2004-03-01 3:07 UTC (permalink / raw)
To: Theo de Raadt; +Cc: Andrew Pinski, tech, Marc Espie, gcc@gcc.gnu.org List
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 3:07 ` Daniel Jacobowitz
@ 2004-03-01 3:46 ` Theo de Raadt
2004-03-01 3:55 ` Gabriel Dos Reis
0 siblings, 1 reply; 25+ messages in thread
From: Theo de Raadt @ 2004-03-01 3:46 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Andrew Pinski, tech, Marc Espie, gcc@gcc.gnu.org List
> > > 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).
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 3:46 ` Theo de Raadt
@ 2004-03-01 3:55 ` Gabriel Dos Reis
2004-03-01 3:59 ` Theo de Raadt
0 siblings, 1 reply; 25+ messages in thread
From: Gabriel Dos Reis @ 2004-03-01 3:55 UTC (permalink / raw)
To: Theo de Raadt
Cc: Daniel Jacobowitz, Andrew Pinski, tech, Marc Espie, gcc@gcc.gnu.org List
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 3:55 ` Gabriel Dos Reis
@ 2004-03-01 3:59 ` Theo de Raadt
2004-03-01 4:15 ` Daniel Berlin
2004-03-01 6:00 ` Andreas Jaeger
0 siblings, 2 replies; 25+ messages in thread
From: Theo de Raadt @ 2004-03-01 3:59 UTC (permalink / raw)
To: Gabriel Dos Reis
Cc: Daniel Jacobowitz, Andrew Pinski, tech, Marc Espie, gcc@gcc.gnu.org List
> (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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 3:59 ` Theo de Raadt
@ 2004-03-01 4:15 ` Daniel Berlin
2004-03-14 22:15 ` Gerald Pfeifer
2004-03-01 6:00 ` Andreas Jaeger
1 sibling, 1 reply; 25+ messages in thread
From: Daniel Berlin @ 2004-03-01 4:15 UTC (permalink / raw)
To: Theo de Raadt
Cc: tech, gcc@gcc.gnu.org List, Daniel Jacobowitz, Gabriel Dos Reis,
Marc Espie, Andrew Pinski
>
> 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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 4:15 ` Daniel Berlin
@ 2004-03-14 22:15 ` Gerald Pfeifer
0 siblings, 0 replies; 25+ messages in thread
From: Gerald Pfeifer @ 2004-03-14 22:15 UTC (permalink / raw)
To: Theo de Raadt, tech
Cc: gcc, Daniel Berlin, Daniel Jacobowitz, Gabriel Dos Reis,
Marc Espie, Andrew Pinski
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/
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 3:59 ` Theo de Raadt
2004-03-01 4:15 ` Daniel Berlin
@ 2004-03-01 6:00 ` Andreas Jaeger
2004-03-01 19:40 ` Peter Galbavy
1 sibling, 1 reply; 25+ messages in thread
From: Andreas Jaeger @ 2004-03-01 6:00 UTC (permalink / raw)
To: Theo de Raadt
Cc: Gabriel Dos Reis, Daniel Jacobowitz, Andrew Pinski, tech,
Marc Espie, gcc@gcc.gnu.org List
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 6:00 ` Andreas Jaeger
@ 2004-03-01 19:40 ` Peter Galbavy
2004-03-01 19:51 ` Andreas Jaeger
0 siblings, 1 reply; 25+ messages in thread
From: Peter Galbavy @ 2004-03-01 19:40 UTC (permalink / raw)
To: Theo de Raadt, Andreas Jaeger
Cc: Gabriel Dos Reis, Daniel Jacobowitz, Andrew Pinski, tech,
Marc Espie, gcc
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 19:40 ` Peter Galbavy
@ 2004-03-01 19:51 ` Andreas Jaeger
2004-03-01 20:05 ` Peter Galbavy
0 siblings, 1 reply; 25+ messages in thread
From: Andreas Jaeger @ 2004-03-01 19:51 UTC (permalink / raw)
To: Peter Galbavy
Cc: Theo de Raadt, Gabriel Dos Reis, Daniel Jacobowitz,
Andrew Pinski, tech, Marc Espie, gcc
[-- 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 --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 19:51 ` Andreas Jaeger
@ 2004-03-01 20:05 ` Peter Galbavy
2004-03-01 20:15 ` William Ahern
0 siblings, 1 reply; 25+ messages in thread
From: Peter Galbavy @ 2004-03-01 20:05 UTC (permalink / raw)
To: Andreas Jaeger
Cc: Theo de Raadt, Gabriel Dos Reis, Daniel Jacobowitz,
Andrew Pinski, tech, Marc Espie, gcc
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 20:05 ` Peter Galbavy
@ 2004-03-01 20:15 ` William Ahern
0 siblings, 0 replies; 25+ messages in thread
From: William Ahern @ 2004-03-01 20:15 UTC (permalink / raw)
To: Peter Galbavy
Cc: Andreas Jaeger, Theo de Raadt, Gabriel Dos Reis,
Daniel Jacobowitz, Andrew Pinski, tech, Marc Espie, gcc
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 2:58 ` Theo de Raadt
2004-03-01 3:07 ` Daniel Jacobowitz
@ 2004-03-01 3:10 ` Zack Weinberg
2004-03-01 3:49 ` Theo de Raadt
2004-03-01 8:09 ` Steven Bosscher
2 siblings, 1 reply; 25+ messages in thread
From: Zack Weinberg @ 2004-03-01 3:10 UTC (permalink / raw)
To: Theo de Raadt; +Cc: Andrew Pinski, tech, Marc Espie, gcc@gcc.gnu.org List
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 3:10 ` Zack Weinberg
@ 2004-03-01 3:49 ` Theo de Raadt
2004-03-01 4:00 ` Eric Christopher
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Theo de Raadt @ 2004-03-01 3:49 UTC (permalink / raw)
To: Zack Weinberg; +Cc: Andrew Pinski, tech, Marc Espie, gcc@gcc.gnu.org List
> 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?
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 3:49 ` Theo de Raadt
@ 2004-03-01 4:00 ` Eric Christopher
2004-03-01 4:05 ` Theo de Raadt
2004-03-01 4:00 ` Gabriel Dos Reis
2004-03-01 4:01 ` Zack Weinberg
2 siblings, 1 reply; 25+ messages in thread
From: Eric Christopher @ 2004-03-01 4:00 UTC (permalink / raw)
To: Theo de Raadt
Cc: Zack Weinberg, Andrew Pinski, tech, Marc Espie, gcc@gcc.gnu.org List
>
> 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>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 4:00 ` Eric Christopher
@ 2004-03-01 4:05 ` Theo de Raadt
2004-03-01 4:11 ` Eric Christopher
0 siblings, 1 reply; 25+ messages in thread
From: Theo de Raadt @ 2004-03-01 4:05 UTC (permalink / raw)
To: Eric Christopher
Cc: Zack Weinberg, Andrew Pinski, tech, Marc Espie, gcc@gcc.gnu.org List
> 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...
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 4:05 ` Theo de Raadt
@ 2004-03-01 4:11 ` Eric Christopher
0 siblings, 0 replies; 25+ messages in thread
From: Eric Christopher @ 2004-03-01 4:11 UTC (permalink / raw)
To: Theo de Raadt
Cc: Zack Weinberg, Andrew Pinski, tech, Marc Espie, gcc@gcc.gnu.org List
> 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>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 3:49 ` Theo de Raadt
2004-03-01 4:00 ` Eric Christopher
@ 2004-03-01 4:00 ` Gabriel Dos Reis
2004-03-01 4:01 ` Zack Weinberg
2 siblings, 0 replies; 25+ messages in thread
From: Gabriel Dos Reis @ 2004-03-01 4:00 UTC (permalink / raw)
To: Theo de Raadt
Cc: Zack Weinberg, Andrew Pinski, tech, Marc Espie, gcc@gcc.gnu.org List
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 3:49 ` Theo de Raadt
2004-03-01 4:00 ` Eric Christopher
2004-03-01 4:00 ` Gabriel Dos Reis
@ 2004-03-01 4:01 ` Zack Weinberg
[not found] ` <20040301071403.GA8953@tetto.gentiane.org>
2 siblings, 1 reply; 25+ messages in thread
From: Zack Weinberg @ 2004-03-01 4:01 UTC (permalink / raw)
To: Theo de Raadt; +Cc: Andrew Pinski, tech, Marc Espie, gcc@gcc.gnu.org List
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: gcc and compiling speed
2004-03-01 2:58 ` Theo de Raadt
2004-03-01 3:07 ` Daniel Jacobowitz
2004-03-01 3:10 ` Zack Weinberg
@ 2004-03-01 8:09 ` Steven Bosscher
2 siblings, 0 replies; 25+ messages in thread
From: Steven Bosscher @ 2004-03-01 8:09 UTC (permalink / raw)
To: Theo de Raadt, Andrew Pinski; +Cc: tech, Marc Espie, gcc@gcc.gnu.org List
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/
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2004-03-14 22:15 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-01 4:23 gcc and compiling speed Vincent Diepeveen
2004-03-01 5:00 ` John S. Dyson
2004-03-01 5:31 ` Zack Weinberg
-- strict thread matches above, loose matches on Subject: below --
2004-03-01 0:43 Andrew Pinski
2004-03-01 2:58 ` Theo de Raadt
2004-03-01 3:07 ` Daniel Jacobowitz
2004-03-01 3:46 ` Theo de Raadt
2004-03-01 3:55 ` Gabriel Dos Reis
2004-03-01 3:59 ` Theo de Raadt
2004-03-01 4:15 ` Daniel Berlin
2004-03-14 22:15 ` Gerald Pfeifer
2004-03-01 6:00 ` Andreas Jaeger
2004-03-01 19:40 ` Peter Galbavy
2004-03-01 19:51 ` Andreas Jaeger
2004-03-01 20:05 ` Peter Galbavy
2004-03-01 20:15 ` William Ahern
2004-03-01 3:10 ` Zack Weinberg
2004-03-01 3:49 ` Theo de Raadt
2004-03-01 4:00 ` Eric Christopher
2004-03-01 4:05 ` Theo de Raadt
2004-03-01 4:11 ` Eric Christopher
2004-03-01 4:00 ` Gabriel Dos Reis
2004-03-01 4:01 ` Zack Weinberg
[not found] ` <20040301071403.GA8953@tetto.gentiane.org>
2004-03-01 7:27 ` Zack Weinberg
2004-03-01 8:09 ` Steven Bosscher
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).