On 7/21/09 9:22 AM, "Scott Marlowe" <scott.marlowe@xxxxxxxxx> wrote: >> But, the real point is that "thread" (whether "CoolThread" or "HT" thread), >> is not the same as core, which is not the same as processor. X 2 threads is >> usually significantly less benefit than X 2 cores. X 2 cores is probably >> less benefit than X 2 processors. > > Actually, given the faster inter-connect speed and communication, I'd > think a single quad core CPU would be faster than the equivalent dual > dual core cpu. Its very workload dependant and system dependant. If the dual core dual cpu setup has 2x the memory bandwidth of the single quad core (Nehalem, Opteron), it also likely has higher memory latency and a dedicated interconnect for memory and cache coherency. And so some workloads will favor the low latency and others will favor more bandwidth. If its like the older Xeons, where an extra CPU doesn't buy you more memory bandwidth alone (but better chipsets do), then a single quad core is usually faster than dual core dual cpu (if the same chipset). Even more so if there is a lot of lock contention, since that can all be handled on the same CPU rather than communicating across the bus. But back on topic for HT -- HT doesn't like spin-locks much unless they use the right low level instruction sequence rather than actually spinning. With the right instruction, the spin will allow the other thread to do work... With the wrong one, it will tie up the pipeline. I have no idea what Postgres' spin-locks and tool chain compile down to. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
