From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32685 invoked by alias); 1 Mar 2004 04:15:51 -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 32677 invoked from network); 1 Mar 2004 04:15:50 -0000 Received: from unknown (HELO dberlin.org) (69.3.5.6) by sources.redhat.com with SMTP; 1 Mar 2004 04:15:50 -0000 Received: from [192.168.1.7] (account dberlin [192.168.1.7] verified) by dberlin.org (CommuniGate Pro SMTP 4.1.4) with ESMTP-TLS id 6101700; Sun, 29 Feb 2004 23:15:48 -0500 In-Reply-To: <200403010359.i213xcqp005885@cvs.openbsd.org> References: <200403010359.i213xcqp005885@cvs.openbsd.org> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1D8A5296-6B37-11D8-B42E-000A95DA505C@dberlin.org> Content-Transfer-Encoding: 7bit Cc: tech@openbsd.org, "gcc@gcc.gnu.org List" , Daniel Jacobowitz , Gabriel Dos Reis , Marc Espie , Andrew Pinski From: Daniel Berlin Subject: Re: gcc and compiling speed Date: Mon, 01 Mar 2004 04:15:00 -0000 To: Theo de Raadt X-SW-Source: 2004-03/txt/msg00025.txt.bz2 > > 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 and gcc > 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.