Re: Large (8M) cache vs. dual-core CPUs

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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461