From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27237 invoked by alias); 20 Jan 2004 22:30:05 -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 27230 invoked from network); 20 Jan 2004 22:30:04 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sources.redhat.com with SMTP; 20 Jan 2004 22:30:04 -0000 Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id i0KMU4cb010686 for ; Tue, 20 Jan 2004 14:30:04 -0800 (PST) Received: from relay3.apple.com (relay3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Tue, 20 Jan 2004 14:30:04 -0800 Received: from [17.219.199.36] ([17.219.199.36]) by relay3.apple.com (8.12.10/8.12.9) with ESMTP id i0KMTBN8013741; Tue, 20 Jan 2004 22:30:03 GMT In-Reply-To: References: <90200277-4301-11D8-BDBD-000A95B1F520@apple.com> <200401192120.53057.ebotcazou@libertysurf.fr> <51C2CB76-4AC7-11D8-90DA-0030657EA24A@apple.com> <200401192304.01694.ebotcazou@libertysurf.fr> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <31870CEE-4B98-11D8-83EB-000A95B1F520@apple.com> Content-Transfer-Encoding: 7bit Cc: Scott Robert Ladd , Robert Dewar , gcc@gcc.gnu.org, Nick Burrett , Eric Botcazou , Gabriel Dos Reis , Marc Espie From: Geoffrey Keating Subject: Re: gcc 3.5 integration branch proposal Date: Tue, 20 Jan 2004 22:30:00 -0000 To: Alexandre Oliva X-SW-Source: 2004-01/txt/msg01578.txt.bz2 On 20/01/2004, at 2:11 PM, Alexandre Oliva wrote: > On Jan 20, 2004, Geoffrey Keating wrote: > >>> Err... And under what kind of logic is getting the compiler slower >>> not a waste of time for every GCC developer (that has to bootstrap >>> and >>> test the whole thing for every patch) and user (that runs GCC to >>> build >>> their own applications). > >> I didn't say the developer should make GCC slower. I said the >> developer should not worry about performance on *old* machines. >> Performance on *new* machines is still a concern. They are often not >> the same thing. > > I don't see how making GCC faster on new machines wouldn't speed > things up on slower machines. Hmm... Except for refraining from > recomputing stuff over and over by setting aside some memory to hold > the computed value. This is fine for machines with lots of memory, > but not for memory-starved machines, which are more likely to be the > slow ones. But then, for a sufficiently large testcase, setting such > memory aside might cause even fast and big-memory boxes to get > slower. > > Do you have other situations in mind? Typically, on older, slower machines (eg. the mentioned 300Mhz StrongARM), memory accesses are relatively cheap relative to computation. Thus, on newer machines it's useful to perform some computation if this results in smaller final data structures, but this is not true on older machines.