Hi!
On Fri, Aug 27, 2010 at 12:55 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> Scott Carey wrote:
>>
>> But the select count(*) query, cached in RAM is 3x faster in one system
>> than the other. The CPUs aren't 3x different performance wise. Something
>> else may be wrong here.
>>
>> An individual Core2 Duo 2.93Ghz should be at most 50% faster than a 2.2Ghz
>> Opteron for such a query. Unless there are some compile options that are
>> set wrong. I would check the compile options.
>>
>
> Sure, it might be. But I've seen RAM on an Intel chip like the E7500 here
> (DDR3-1066 or better, around 10GB/s possible) run almost 3X as fast as what
> you'll find paired with an Opteron 2427 (DDR2-800, closer to 3.5GB/s).
> Throw in the clock differences and there you go.
Precisely! CPU core clock is not all that matters, specially when it
comes to work with large datasets. CPU core clock will only make a
difference with relatively small (ie, that fits on cpu cache) code
that works with a relatively small (ie, that *also* fits on cpu cache)
dataset, for example, a series PI calculation, or a simple prime
number generation algorithm, but when it comes to large amounts of
data/code, the RAM starts to play a vital role, and not just "raw" RAM
speed, but latency!!! (a combination of them both) some people just go
for the "fastest" RAM around, but they don't pay attention to latency
numbers, you need to get the fastest RAM with the slowest latency.
Also, nowadays, Intel has better performance than AMD, at least when
comparing Athlon 64 vs Core2, I'm still saving to get a Phenom II
system in order to benchmark them and see how it goes (does anyone
have one of these for testing?).
>
> I've been wandering around for years warning that the older Opterons on DDR2
> running a single PostgreSQL process are dog slow compared to the same thing
> on Intel. So that alone might actually be enough to account for the
> difference. Ultimately the multi-processor stuff is what's more important
> to most apps, though, which is why I was hinting to properly run that
> instead.
>
> --
> Greg Smith 2ndQuadrant US Baltimore, MD
> PostgreSQL Training, Services and Support
> greg@2ndQuadrant.com www.2ndQuadrant.us
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
