From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28144 invoked by alias); 27 Nov 2007 19:35:47 -0000 Received: (qmail 28131 invoked by uid 22791); 27 Nov 2007 19:35:45 -0000 X-Spam-Check-By: sourceware.org Received: from exprod6og56.obsmtp.com (HELO exprod6og56.obsmtp.com) (64.18.1.208) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 27 Nov 2007 19:35:36 +0000 Received: from source ([192.150.20.142]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Tue, 27 Nov 2007 11:35:30 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lARJZRNT003886; Tue, 27 Nov 2007 11:35:28 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lARJXEG1006642; Tue, 27 Nov 2007 11:35:27 -0800 (PST) Received: from namailgen.corp.adobe.com ([10.8.192.91]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 11:35:23 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: reduce compilation times? Date: Tue, 27 Nov 2007 19:41:00 -0000 Message-ID: References: <998d0e4a0711270748x224a16d5ye84fc0eae5ac90d5@mail.gmail.com> <5abcb5650711270804o171e1facr565beec70314af75@mail.gmail.com> <998d0e4a0711270827j6c8f3a41h4d02c62c604a27cf@mail.gmail.com> <474C4940.4010809@ellipticsemi.com> From: "John (Eljay) Love-Jensen" To: "NightStrike" , "Tom St Denis" Cc: "J.C. Pizarro" , "Galloth" , X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg00316.txt.bz2 Hi NightStrike, > Is there a difference in the speed of the resulting program when everythi= ng is split into many object files instead of being combined into a single = main.c ...? There may be a negative small performance impact in a resulting program tha= t is split into many object files instead of being combined into a single m= ain.c. (My expectation is that, overall, the performance impact will be ne= gligible if it is even measurable.) There may be a few interoperating routines that are strongly negatively imp= acted by being split into many object files instead of being combined into = a single object file. (My expectation for these particular routines is tha= t they should be heavily optimized, perhaps even being rewritten in lovingl= y handcrafted assembly -- assuming assembly chops are superior to the optim= izing compiler's amazing optimizations.) If not re-written in hand coded a= ssembly, at least having performance critical routines' code hand-tweaked t= o allow the GCC optimizer to do it's best to optimize it would be prudent (= including using inline functions, and avoiding the anti-patterns that cripp= le optimization). The way to assess those routines is through profiling. GCC does not do "holistic" optimizations (yet). In contrast, LLVM does "ho= listic" optimizations. >... or is the resulting binary identical bit for bit? No, the resulting binary is not identical bit-for-bit. It should be identical output for identical input. (Barring non-compliant = or undefined behavior code, of course.) HTH, --Eljay