Re: AMD Shanghai versus Intel Nehalem

From: Scott Carey <scott(at)richrelevance(dot)com>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: Arjen van der Meijden <acmmailing(at)tweakers(dot)net>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: AMD Shanghai versus Intel Nehalem
Date: 2009-05-14 17:01:02
Message-ID: C6319C5E.6141%scott@richrelevance.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


On 5/13/09 11:52 PM, "Greg Smith" <gsmith(at)gregsmith(dot)com> wrote:

> On Wed, 13 May 2009, Scott Carey wrote:
>
>> Can you do a quick and dirty memory bandwidth test? (assuming linux)
>>
>> /sbin/hdparm -T /dev/sd<device>
>>
>> ...its not a very accurate measurement, but its quick and highlights
>> relative hardware differences very easily.
>
> I've found "hdparm -T" to be useful for comparing the relative memory
> bandwidth of a given system as I change its RAM configuration around, but
> that's about it. I've seen that result change by a factor of 2X just by
> changing kernel version on the same hardware. The data volume transferred
> doesn't seem to be nearly enough to extract the true RAM speed from
> (guessing the cause here) things like whether the test/kernel code fits
> into the CPU cache.

That's too bad -- I have been using it to compare machines as well, but they
are all on the same Linux version / distro.

Regardless -- the results indicate a 2x to 3x bandwidth improvement... Which
sounds about right if the older CPU isn't on the newer FBDIMM chipset. If
both of those machines are on the same Kernel, the relative values should be
a somewhat valid (though -- definitely not all that accurate).

>
> I'm using this nowadays:
>
> sysbench --test=memory --memory-oper=write --memory-block-size=1024MB
> --memory-total-size=1024MB run
>

Unfortunately, sysbench isn't installed by default on many (most?) distros,
or even available as a package on many. So its a bigger 'ask' to get
results from it. Certainly a significantly better overall tool.

> The sysbench read test looks similarly borked by caching effects when I've
> tried it, but if you write that much it seems to give useful results.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Simon Riggs 2009-05-14 17:03:47 Re: Any better plan for this query?..
Previous Message Tom Lane 2009-05-14 15:20:33 Re: UNION ALL and sequential scans