From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9542 invoked by alias); 20 Jan 2004 22:04:22 -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 9531 invoked from network); 20 Jan 2004 22:04:20 -0000 Received: from unknown (HELO desire.geoffk.org) (67.169.96.182) by sources.redhat.com with SMTP; 20 Jan 2004 22:04:20 -0000 Received: from desire.geoffk.org (localhost.localdomain [127.0.0.1]) by desire.geoffk.org (8.12.10/8.12.10) with ESMTP id i0KM4GQ0022082; Tue, 20 Jan 2004 14:04:16 -0800 Received: (from geoffk@localhost) by desire.geoffk.org (8.12.10/8.12.10/Submit) id i0KM4FGe022078; Tue, 20 Jan 2004 14:04:15 -0800 X-Authentication-Warning: desire.geoffk.org: geoffk set sender to geoffk@geoffk.org using -f To: "Zack Weinberg" Cc: Nick Burrett , gcc@gcc.gnu.org, Gabriel Dos Reis , Marc Espie , Jan Hubicka Subject: Re: gcc 3.5 integration branch proposal References: <82D6F34E-4306-11D8-BDBD-000A95B1F520@apple.com> <20040110154129.GA28152@disaster.jaj.com> <1073935323.3458.42.camel@minax.codesourcery.com> <1073951351.3458.162.camel@minax.codesourcery.com> <20040119013113.044D74895@quatramaran.ens.fr> <400BB40B.4070101@dsvr.net> <871xpvp9d7.fsf@egil.codesourcery.com> <20040120100839.GA21361@atrey.karlin.mff.cuni.cz> <87u12qo5s2.fsf@egil.codesourcery.com> <3DF1B3B1-4B79-11D8-83EB-000A95B1F520@apple.com> <87fzeao355.fsf@egil.codesourcery.com> From: Geoff Keating Date: Tue, 20 Jan 2004 22:04:00 -0000 In-Reply-To: <87fzeao355.fsf@egil.codesourcery.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-01/txt/msg01571.txt.bz2 "Zack Weinberg" writes: > Geoffrey Keating writes: > >> One cause of excessive memset that I have wanted to address for years > >> is, make_node() clears the entire tree node - but make_node is almost > >> always called from somewhere that's going to fill in most or all of > >> the fields anyway. We ought to have something like the gen_rtx_fmt_* > >> functions for tree nodes. > > > > You're looking at this the wrong way. We have to load the object into > > cache anyway, it does not really matter if make_node does it or it's > > done later. > > > > I'll emphasize Jan's comment: when you analyze GCC performance, you > > can usually disregard all code that doesn't cause cache faults. > > I think you misunderstand what I was saying, or else my testing is on > chips with very different cache behavior. > > The current effect is, make_node loads and zeroes the entire node, and > then most fields of that are rewritten with live data. I don't have > numbers to say what that does for trees, but I know that cpplib used > to do similar things to its own data structures, and changing it not > to was good for an overall 1-2% on wall clock time running gcc -E. > > Fundamentally, cutting down the write traffic even just to L1 can't be > a bad thing. Yes; this kind of logic is why many people waste a lot of time optimising the wrong place in their code. Logically, deleting instructions means the processor has to do less work and therefore makes the program faster. In practise, though, a write to L1 cache takes about 1/3 cycle, but a L2 cache miss takes ~100, and so L2 cache misses dominate execution time. Now, if you're cpplib, and you're zeroing a structure on the stack, the arithmetic is different, since the stack is usually hot. This is not cpplib. -- - Geoffrey Keating