From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18428 invoked by alias); 2 Jan 2003 14:24:55 -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 18406 invoked from network); 2 Jan 2003 14:24:54 -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:24:54 -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 D1E894DE18; Thu, 2 Jan 2003 15:24:45 +0100 (CET) Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Thu, 2 Jan 2003 15:24:50 +0100 Date: Thu, 02 Jan 2003 14:24:00 -0000 From: Jan Hubicka To: Steven Bosscher Cc: Neil Booth , Andreas Jaeger , gcc@gcc.gnu.org Subject: Re: GCC still getting a lot slower Message-ID: <20030102142450.GB21227@kam.mff.cuni.cz> References: <1041382480.23232.35.camel@steven> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1041382480.23232.35.camel@steven> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-01/txt/msg00034.txt.bz2 > Neil Booth wrote: > > > Any idea what killed GCC bootstrap time in Mid-Dec? This really must > > stop happening; we're out of control. > > > > http://www.suse.de/~aj/SPEC/CINT/d-permanent/times.html > > Just curious: > > When the B-I-B branch was announced in > http://gcc.gnu.org/ml/gcc/2002-08/msg01575.html, the announcement also > spoke of the "faster-compiler-branch", but it seems that this branch was > never used (at least, I can't find any mails about it). The announcement > mentions a few bottlenecks, and IIRC from some other mails by Zack at > least some bottlenecks are known. Could somebody make a list of those (I > can make that+whatever else into a nice XHTML page for this branch...)? > This would also look like the right branch to play with Dan's memory > work... > > There are two SPEC testers and a regression tester, but is there a > cachegrind tester, or a tester that collects profile data? I have simple scripts to collect oprofile data (including the anotated disassembly of hot spots) I am using to tune compiler and have data usually for few weeks back. The data are quite usefull to easilly fix the problem, but somewhat large to be practical to collect regularry. Even the current SPEC testers has problem with disc capacity Honza > > Greetz > Steven >