From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6039 invoked by alias); 1 Mar 2004 08:09:10 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 6031 invoked from network); 1 Mar 2004 08:09:09 -0000 Received: from unknown (HELO mailhost2.tudelft.nl) (130.161.180.2) by sources.redhat.com with SMTP; 1 Mar 2004 08:09:09 -0000 Received: from localhost (localhost [127.0.0.1]) by rav.antivirus (Postfix) with ESMTP id 27F11BC63; Mon, 1 Mar 2004 09:09:09 +0100 (MET) Received: from listserv.tudelft.nl (listserv.tudelft.nl [130.161.180.33]) by mailhost2.tudelft.nl (Postfix) with ESMTP id A97406237; Mon, 1 Mar 2004 09:09:08 +0100 (MET) Received: from steven.lr-s.tudelft.nl (hekje1.shuis.tudelft.nl [145.94.192.78]) by listserv.tudelft.nl (8.12.10/8.12.8) with ESMTP id i21893DQ007752; Mon, 1 Mar 2004 09:09:03 +0100 (MET) Received: by steven.lr-s.tudelft.nl (Postfix, from userid 500) id B3FF9F357E; Mon, 1 Mar 2004 09:07:49 +0100 (CET) From: Steven Bosscher To: Theo de Raadt , Andrew Pinski Subject: Re: gcc and compiling speed Date: Mon, 01 Mar 2004 08:09:00 -0000 User-Agent: KMail/1.5.4 Cc: tech@openbsd.org, Marc Espie , "gcc@gcc.gnu.org List" References: <200403010259.i212xS6m023756@cvs.openbsd.org> In-Reply-To: <200403010259.i212xS6m023756@cvs.openbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403010907.49515.s.bosscher@student.tudelft.nl> X-Virus-Scanned: by amavisd-new at tudelft.nl X-SW-Source: 2004-03/txt/msg00042.txt.bz2 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/