From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21057 invoked by alias); 8 Oct 2012 19:26:04 -0000 Received: (qmail 21047 invoked by uid 22791); 8 Oct 2012 19:26:03 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta12.emeryville.ca.mail.comcast.net (HELO qmta12.emeryville.ca.mail.comcast.net) (76.96.27.227) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 08 Oct 2012 19:25:59 +0000 Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta12.emeryville.ca.mail.comcast.net with comcast id 8enc1k0051vN32cACjRzAq; Mon, 08 Oct 2012 19:25:59 +0000 Received: from bag6-1-pt.tunnel.tserv3.fmt2.ipv6.he.net ([IPv6:2001:470:1f04:ae1::2]) by omta22.emeryville.ca.mail.comcast.net with comcast id 8jRy1k0090P3DwE8ijRyze; Mon, 08 Oct 2012 19:25:59 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Subject: Re: Convert more non-GTY htab_t to hash_table. From: Mike Stump In-Reply-To: Date: Mon, 08 Oct 2012 19:26:00 -0000 Cc: Lawrence Crowl , Jakub Jelinek , Richard Guenther , gcc-patches List Content-Transfer-Encoding: quoted-printable Message-Id: <5D8D5283-930E-498C-AC45-460252B027FD@comcast.net> References: <20121005211617.GM1787@tucnak.redhat.com> To: Diego Novillo 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: 2012-10/txt/msg00802.txt.bz2 On Oct 5, 2012, at 3:19 PM, Diego Novillo wrote: > On Fri, Oct 5, 2012 at 6:08 PM, Lawrence Crowl wrote: >=20 >>> For many people the time to compile (almost) empty file is very >>> important, we are already bad about that right now, initializing >>> too much stuff dynamically is going to make it worse. >>=20 >> So far, we are looking at dynamic initializations that would >> take about 10 cycles. Even on a slow processor, a thousand >> initializations would take a microsecond. Our time reports don't >> even report anything less than 5 milliseconds. >>=20 >> Is there any reason to believe that this anticipated static >> initialization overhead is not pretty low relative to other overhead? >> I'm thinking here of the fact that to even start, the driver launches >> cc1[plus] which has to parse all the options created by the driver. >=20 > I agree. I don't think this will be a real problem. I hope you're right. Experience tells me that the usual high cost a single= dynamic initialization is 30,000,000 cycles, about 100 of them cost 1 seco= nd. Costs of the low side, are completely irrelevant. I think the 10 cycl= e cost is not the high side, but the irrelevant low side number. If one wa= nted to understand the actual cost one can take a snap of the cycle counter= before the dynamic inits happen (or near the front of them) and take a sna= p of it after they run, and examine the difference=85 A difference of 0, m= eans, though one might conceive of them as dynamic inits, they are not. An= d the other number is what it is. A global cycle counter that free runs as= a time of day counter can see the page faults, tlb misses and all the othe= r hair, while per process cpu used counter is less useful.