From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5254 invoked by alias); 1 Mar 2004 04:23:42 -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 5241 invoked from network); 1 Mar 2004 04:23:42 -0000 Received: from unknown (HELO smtp-out6.xs4all.nl) (194.109.24.7) by sources.redhat.com with SMTP; 1 Mar 2004 04:23:42 -0000 Received: from venezia (213-84-245-71.adsl.xs4all.nl [213.84.245.71]) by smtp-out6.xs4all.nl (8.12.10/8.12.10) with SMTP id i214Nf0F058401 for ; Mon, 1 Mar 2004 05:23:41 +0100 (CET) Message-Id: <3.0.32.20040301052358.01341500@pop.xs4all.nl> X-Sender: diep@pop.xs4all.nl Date: Mon, 01 Mar 2004 04:23:00 -0000 To: "gcc@gcc.gnu.org List" From: Vincent Diepeveen Subject: Re: gcc and compiling speed Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2004-03/txt/msg00027.txt.bz2 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...