From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2843 invoked by alias); 9 Aug 2010 15:26:16 -0000 Received: (qmail 2809 invoked by uid 22791); 9 Aug 2010 15:26:14 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.35) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Aug 2010 15:26:08 +0000 Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o79FQ5HL022692 for ; Mon, 9 Aug 2010 08:26:05 -0700 Received: from qwf7 (qwf7.prod.google.com [10.241.194.71]) by kpbe20.cbf.corp.google.com with ESMTP id o79FQ3ng028092 for ; Mon, 9 Aug 2010 08:26:04 -0700 Received: by qwf7 with SMTP id 7so8724168qwf.39 for ; Mon, 09 Aug 2010 08:26:03 -0700 (PDT) Received: by 10.229.215.67 with SMTP id hd3mr7389067qcb.74.1281367562627; Mon, 09 Aug 2010 08:26:02 -0700 (PDT) Received: from dnovillo-macbookpro.local (CPE00259cc50085-CM00222d76229d.cpe.net.cable.rogers.com [99.230.181.221]) by mx.google.com with ESMTPS id t1sm6453154qcs.33.2010.08.09.08.26.01 (version=SSLv3 cipher=RC4-MD5); Mon, 09 Aug 2010 08:26:01 -0700 (PDT) Message-ID: <4C601E08.4020303@google.com> Date: Mon, 09 Aug 2010 15:33:00 -0000 From: Diego Novillo User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Toon Moene CC: Steven Bosscher , Bernd Schmidt , Eric Botcazou , Richard Guenther , gcc-patches@gcc.gnu.org Subject: Re: The speed of the compiler, was: Re: Combine four insns References: <4C5C20D0.5020105@codesourcery.com> <4C5C8F7C.6010509@codesourcery.com> <201008071010.53419.ebotcazou@adacore.com> <4C5FEF18.7010504@codesourcery.com> <4C6011F7.5040904@moene.org> <4C601691.1000303@moene.org> In-Reply-To: <4C601691.1000303@moene.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-08/txt/msg00678.txt.bz2 On 10-08-09 10:54 , Toon Moene wrote: > Most of these "compiles" are -O0 -g compiles, for obvious reasons (why > spend time on optimization when you don't even know the code is correct ?) Internally, we have been working on build time improvements for a few months. We are not looking at just the compiler, but the entire toolchain. As I've posted in other threads, our main consumer of compilation time is the C++ front end. Hands down. It consistently takes between 70% and 80% of compilation time across the board. Furthermore, this is independent from the optimization level. The optimizers never take more than 10-15% of total compilation time, on average. We are also looking at incremental linking and addressing performance problems in the build system itself. But for the compiler, our focus is just the C++ front end. We are trying to incorporate more caching into the system. We already have ccache style caches, so we are trying finer grained approaches. We tried using pre-compiled headers earlier this year, but it just didn't work. PCH caches the transitive closure of the translation unit, so if just one file changes, you need to re-compile the whole TU again. It was also space prohibitive (caching the different versions required). Currently, we are prototyping front end changes for caching tokens and parsing results. We are not yet up to the point where we can tell whether it will work, though. The one interesting result we found so far is that in looking at the whole toolchain, it may be worth *slowing* down some components to speedup the whole process. In particular, we have found that using -Os as our default build setting, actually decreases build time by 15% to 20%. The compiler spends a bit more time optimizing (almost unnoticeable in general), but the resulting smaller objects and binaries more than compensate for it. It speeds up linking, I/O, transmission times, etc. Additionally, the very worst offender in terms of compile time is -g. The size of debugging information is such, that I/O and communication times increase significantly. Diego.