On Tue, 28 Jul 2009, Scott Carey wrote:
> On 7/28/09 1:28 PM, "Greg Smith" <gsmith@gregsmith.com> wrote:
>> On Tue, 28 Jul 2009, Matthew Wakeling wrote:
>>
>>> Unlikely. Different threads on the same CPU core share their resources, so
>>> they don't need an explicit communication channel at all (I'm simplifying
>>> massively here). A real interconnect is only needed between CPUs and between
>>> different cores on a CPU, and of course to the outside world.
>>
>> The question was "why are the new CPUs benchmarking so much faster than
>> the old ones"...
>
> I believe he was answering the question "What makes SMT work well with
> Postgres for these CPUs when it had problems on old Xeons?"
Exactly. Interconnects and bandwidth are going to make the CPU faster in
general, but won't have any (much?) effect on the relative speed with and
without SMT.
If the new CPUs are four-way dispatch and the old ones were two-way
dispatch, that easily explains why SMT is a bonus on the new CPUs. With a
two-way dispatch, a single thread is likely to be able to keep both
pipelines busy most of the time. Switching on SMT will try to keep the
pipelines busy a bit more, giving a small improvement, however that
improvement is cancelled out by the cache being half the size for each
thread. One of our applications ran 30% slower with SMT enabled on an old
Xeon.
On the new CPUs, it would be very hard for a single thread to keep four
execution pipelines busy, so switching on SMT increases the throughput in
a big way. Also, the bigger caches mean that splitting the cache in half
doesn't have nearly as much impact. That's why SMT is a good thing on the
new CPUs.
However, SMT is always likely to slow down any process that is
single-threaded, if that is the only thread doing significant work on the
machine. It only really shows its benefit when you have more CPU-intensive
processes than real CPU cores.
Matthew
--
In the beginning was the word, and the word was unsigned,
and the main() {} was without form and void...
