From: Jim C. Nasby <jnasby@pervasive.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Scott Marlowe <smarlowe@g2switchworks.com>
Cc: mark@mark.mielke.cc, Bill Moran <wmoran@collaborativefusion.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Large (8M) cache vs. dual-core CPUs
Date: Wed, 26 Apr 2006 17:37:31 -0500
Message-ID: <20060426223731.GE97354@pervasive.com> (raw)
In-Reply-To: <200604262216.k3QMGkk15952@candle.pha.pa.us>
References: <20060426220929.GY97354@pervasive.com>
<200604262216.k3QMGkk15952@candle.pha.pa.us>
On Wed, Apr 26, 2006 at 06:16:46PM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Wed, Apr 26, 2006 at 10:27:18AM -0500, Scott Marlowe wrote:
> > > If you haven't actually run a heavy benchmark of postgresql on the two
> > > architectures, please don't make your decision based on other
> > > benchmarks. Since you've got both a D920 and an X2 3800, that'd be a
> > > great place to start. Mock up some benchmark with a couple dozen
> > > threads hitting the server at once and see if the Intel can keep up. It
> >
> > Or better yet, use dbt* or even pgbench so others can reproduce...
>
> For why Opterons are superior to Intel for PostgreSQL, see:
>
> http://techreport.com/reviews/2005q2/opteron-x75/index.x?pg=2
>
> Section "MESI-MESI-MOESI Banana-fana...". Specifically, this part about
> the Intel implementation:
>
> The processor with the Invalid data in its cache (CPU 0, let's say)
> might then wish to modify that chunk of data, but it could not do so
> while the only valid copy of the data is in the cache of the other
> processor (CPU 1). Instead, CPU 0 would have to wait until CPU 1 wrote
> the modified data back to main memory before proceeding.and that takes
> time, bus bandwidth, and memory bandwidth. This is the great drawback of
> MESI.
>
> 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...)
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: jnasby@pervasive.com, pgman@candle.pha.pa.us, smarlowe@g2switchworks.com, wmoran@collaborativefusion.com
Subject: Re: Large (8M) cache vs. dual-core CPUs
In-Reply-To: <20060426223731.GE97354@pervasive.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox