X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 319F511F60A2 for ; Wed, 26 Apr 2006 23:55:23 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 60826-01 for ; Wed, 26 Apr 2006 23:55:15 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.envysolutions.com (mark.mielke.cc [206.248.142.186]) by postgresql.org (Postfix) with ESMTP id 9E3EC11F620C for ; Wed, 26 Apr 2006 23:55:13 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.envysolutions.com (Postfix) with ESMTP id A0DC91B69C; Wed, 26 Apr 2006 22:56:02 -0400 (EDT) Received: from mail.envysolutions.com ([127.0.0.1]) by localhost (mark.mielke.cc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19057-04; Wed, 26 Apr 2006 22:56:02 -0400 (EDT) Received: by mail.envysolutions.com (Postfix, from userid 500) id 868821B6A4; Wed, 26 Apr 2006 22:56:02 -0400 (EDT) Date: Wed, 26 Apr 2006 22:56:02 -0400 From: mark@mark.mielke.cc To: "Jim C. Nasby" Cc: Bruce Momjian , Scott Marlowe , Bill Moran , pgsql-performance@postgresql.org Subject: Re: Large (8M) cache vs. dual-core CPUs Message-ID: <20060427025602.GA19089@mark.mielke.cc> References: <20060426220929.GY97354@pervasive.com> <200604262216.k3QMGkk15952@candle.pha.pa.us> <20060426223731.GE97354@pervasive.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060426223731.GE97354@pervasive.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: amavisd-new at mail.envysolutions.com X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200604/623 X-Sequence-Number: 18707 On Wed, Apr 26, 2006 at 05:37:31PM -0500, Jim C. Nasby wrote: > On Wed, Apr 26, 2006 at 06:16:46PM -0400, Bruce Momjian wrote: > > AMD transfers the dirty cache line directly from cpu to cpu. I can > > imaging that helping our test-and-set shared memory usage quite a bit. > Wasn't the whole point of test-and-set that it's the recommended way to > do lightweight spinlocks according to AMD/Intel? You'd think they'd have > a way to make that performant on multiple CPUs (though if it's relying > on possibly modifying an underlying data page I can't really think of > how to do that without snaking through the cache...) It's expensive no matter what. One method might be less expensive than another. :-) AMD definately seems to have things right for lowest absolute latency. 2X still sounds like an extreme case - but until I've actually tried a very large, or thread intensive PostgreSQL db on both, I probably shouldn't doubt the work of others too much. :-) Cheers, mark -- mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/