Skip site navigation (1) Skip section navigation (2)

Re: hyperthreaded cpu still an issue in 8.4?

From: Matthew Wakeling <matthew(at)flymine(dot)org>
To: Scott Carey <scott(at)richrelevance(dot)com>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, Dave Youatt <dave(at)meteorsolutions(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: hyperthreaded cpu still an issue in 8.4?
Date: 2009-07-29 11:09:43
Message-ID: alpine.DEB.2.00.0907291200310.19493@aragorn.flymine.org (view raw or flat)
Thread:
Lists: pgsql-performance
On Tue, 28 Jul 2009, Scott Carey wrote:
> On 7/28/09 1:28 PM, "Greg Smith" <gsmith(at)gregsmith(dot)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...

In response to

pgsql-performance by date

Next:From: Matthew WakelingDate: 2009-07-29 11:16:41
Subject: Re: hyperthreaded cpu still an issue in 8.4?
Previous:From: Thomas ZaksekDate: 2009-07-29 10:37:28
Subject: Re: select query performance question

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group