From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16921 invoked by alias); 2 Jan 2003 14:21:25 -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 16871 invoked from network); 2 Jan 2003 14:21:21 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by 209.249.29.67 with SMTP; 2 Jan 2003 14:21:21 -0000 Received: from camelot.ms.mff.cuni.cz (kampanus.ms.mff.cuni.cz [195.113.18.107]) by nikam.ms.mff.cuni.cz (Postfix) with SMTP id 09E7A4DE18; Thu, 2 Jan 2003 15:21:03 +0100 (CET) Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Thu, 2 Jan 2003 15:21:07 +0100 Date: Thu, 02 Jan 2003 14:21:00 -0000 From: Jan Hubicka To: Gerald Pfeifer Cc: Nathanael Nerode , gcc@gcc.gnu.org Subject: Re: GCC still getting a lot slower Message-ID: <20030102142107.GA21227@kam.mff.cuni.cz> References: <20021231214116.GA1953@doctormoo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2003-01/txt/msg00033.txt.bz2 > On Tue, 31 Dec 2002, Nathanael Nerode wrote: > > Can we test compile time change of some *fixed* piece of code, perhaps? > > PR 8361 (http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=8361), > which is basically the old PR 3083, is here for anyone to use. ;-) > > Gerald > > PS: It's no longer a completely fixed piece of code, as it's not possible > to have preprocessed source that is forwards or backwards compatible with > or from current mainline, but I have included two preprocessed files now. It would be perhaps good idea to include the performance of preprocesing as well. That would fix the compatibility too. For C performance I think it can be practical to just benchmark linux kernel build - it is fixed piece as it does not include any external headers, large enought to make measurements hopefully stable enought and tests performance of "usual hand writen C program" that (for C) is about the most important. Fixing performance of computer generated code is important too, but it usually has different problem (like computed jumps, large switch statements and so on) and I tend to believe that still most of code is hand writen. I did some oprofiling in the past on this but didn't find anything obvious to fix. For C++ I am not aware of something like that. > -- > Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.pfeifer.com/gerald/