From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Gh4D8-0001XY-Uv for garchives@archives.gentoo.org; Mon, 06 Nov 2006 13:08:23 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kA6D64Ck005309; Mon, 6 Nov 2006 13:06:04 GMT Received: from mail.randombit.net (lain.randombit.net [66.179.181.40]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id kA6D6370024284 for ; Mon, 6 Nov 2006 13:06:04 GMT Received: by mail.randombit.net (Postfix, from userid 501) id C88C73B60F4; Mon, 6 Nov 2006 08:06:06 -0500 (EST) Date: Mon, 6 Nov 2006 08:06:06 -0500 From: Jack Lloyd To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: Unexpected side effect of GCC 4 Message-ID: <20061106130606.GJ5921@randombit.net> Mail-Followup-To: gentoo-amd64@lists.gentoo.org References: <200611050845.42865.prh@gotadsl.co.uk> <200611061305.31763.volker.armin.hemmann@tu-clausthal.de> <20061106124912.GI5921@randombit.net> <200611061359.33291.volker.armin.hemmann@tu-clausthal.de> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611061359.33291.volker.armin.hemmann@tu-clausthal.de> X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-PGP-Key: http://www.randombit.net/pgpkey.html User-Agent: Mutt/1.5.11 X-Archives-Salt: 128bba93-4681-4e57-b516-cededee083df X-Archives-Hash: e7b06189fc6bb7c149df3304b8296ab4 On Mon, Nov 06, 2006 at 01:59:33PM +0100, Hemmann, Volker Armin wrote: > On Monday 06 November 2006 13:49, Jack Lloyd wrote: > > On Mon, Nov 06, 2006 at 01:05:31PM +0100, Hemmann, Volker Armin wrote: > > > lets ask the other way round. Why should it speed up anything to have > > > X>number of cores? Instead of a single thread per core, compiling > > > happily, you have two or more competing for one core and regularly kick > > > out each others data from the cache. > > > > To account for I/O wait states > > and how often does something wait for io and how often does some data is > purged from the cache, because the other make instance is activated? > > When I switched from j2 to j1, compiling did not take any longer - but the box > way much more usable. OK. On my dual core machine, -j3 seems to be the sweet spot. Simply because something does not work for you does not mean it is going to be universally a bad idea. -- gentoo-amd64@gentoo.org mailing list