* 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 gcc and compiling speed 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 ` Gabriel Dos Reis ` (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 ` Gabriel Dos Reis 2004-03-01 4:00 ` Eric Christopher 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 ` Gabriel Dos Reis @ 2004-03-01 4:00 ` Eric Christopher 2004-03-01 4:05 ` Theo de Raadt 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 ` Gabriel Dos Reis 2004-03-01 4:00 ` Eric Christopher @ 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
[parent not found: <20040301071403.GA8953@tetto.gentiane.org>]
* Re: gcc and compiling speed [not found] ` <20040301071403.GA8953@tetto.gentiane.org> @ 2004-03-01 7:27 ` Zack Weinberg 0 siblings, 0 replies; 25+ messages in thread From: Zack Weinberg @ 2004-03-01 7:27 UTC (permalink / raw) To: Theo de Raadt; +Cc: Andrew Pinski, tech, Marc Espie, gcc@gcc.gnu.org List 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 ^ 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
* 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 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
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 0:43 gcc and compiling speed 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 ` Gabriel Dos Reis 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:01 ` Zack Weinberg [not found] ` <20040301071403.GA8953@tetto.gentiane.org> 2004-03-01 7:27 ` Zack Weinberg 2004-03-01 8:09 ` Steven Bosscher 2004-03-01 4:23 Vincent Diepeveen 2004-03-01 5:00 ` John S. Dyson 2004-03-01 5:31 ` Zack Weinberg
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).