Re: hyperthreaded cpu still an issue in 8.4? - Mailing list pgsql-performance

On 01/-10/-28163 11:59 AM, Greg Smith wrote:
> On Tue, 21 Jul 2009, Doug Hunley wrote:
>
>> Just wondering is the issue referenced in
>> http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
>> is still present in 8.4 or if some tunable (or other) made the use of
>> hyperthreading a non-issue. We're looking to upgrade our servers soon
>> for performance reasons and am trying to determine if more cpus (no
>> HT) or less cpus (with HT) are the way to go.
>
> If you're talking about the hyperthreading in the latest Intel Nehalem
> processors, I've been seeing great PostgreSQL performance from those.
> The kind of weird behavior the old generation hyperthreading designs
> had seems gone.  You can see at
> http://archives.postgresql.org/message-id/alpine.GSO.2.01.0907222158050.16713@westnet.com
> that I've cleared 90K TPS on a 16 core system (2 quad-core
> hyperthreaded processors) running a small test using lots of parallel
> SELECTs.  That would not be possible if there were HT spinlock
> problems still around. There have been both PostgreSQL scaling
> improvments and hardware improvements since the 2005 messages you saw
> there that have combined to clear up the issues there.  While true
> cores would still be better if everything else were equal, it rarely
> is, and I wouldn't hestitate to jump on Intel's bandwagon right now.

Greg, those are compelling numbers for the new Nehalem processors.
Great news for postgresql.  Do you think it's due to the new internal
interconnect, that bears a strong resemblance to AMD's hypertransport
(AMD's buzzword for borrowing lots of interconnect technology from the
DEC alpha (EV7?)), or Intel fixing a not-so-good initial implementation
of "hyperthreading" (Intel's marketing buzzword) from a few years ago.
Also, and this is getting maybe too far off topic, beyond the buzzwords,
what IS  the new "hyperthreading" in Nehalems?  -- opportunistic
superpipelined cpus?, superscalar?  What's shared by the cores
(bandwidth, cache(s))?   What's changed about the new hyperthreading
that makes it actually seem to work (or at least not causes other
problems)?   smarter scheduling of instructions to take advantage of
stalls, hazards another thread's instruction stream?  Fixed
instruction-level locking/interlocks, or avoiding locking whenever
possible?  better cache coherency mechanicms (related to the
interconnects)?  Jedi mind tricks???

I'm guessing it's the better interconnect, but work interferes with
finding the time to research and benchmark.