Antwort: Physical CPU? or multicore?

From: Martin Klier <Martin.Klier_at_klug-is.de>
Date: Mon, 27 Apr 2009 14:54:27 +0200
Message-ID: <OF6198E9A4.EEF4867F-ONC12575A5.0046A09B-C12575A5.0046E763_at_klug-is.de>



Hi Karl,

physical CPUs are always better than Hyperthreading: HT only twins the pipes and queues, for computing itself you will end up with some kind of "contention" on the core again. Okay, Nehalem has improved requeuing features implemented and might be more efficient than the old Xenons, but if licensing does not matter, I'd always prefer real metal.

--
Mit freundlichem Gruß


Martin Klier
Senior Oracle Database Administrator
------------------------------------------------------------------------------

Klug GmbH integrierte Systeme
Lindenweg 13, D-92552 Teunz
Tel.:  +49 9671/9216-245
Fax.: +49 9671/9216-112
mailto: martin.klier_at_klug-is.de
www.klug-is.de
------------------------------------------------------------------------------

Geschäftsführer: Johann Klug, Roman Sorgenfrei
Sitz der Gesellschaft: Teunz, USt-ID-Nr. DE175481608,
HRB Nr. 2037, Amtsgericht Amberg

oracle-l-bounce_at_freelists.org schrieb am 27.04.2009 13:21:36:


> Von:
>
> Karl Arao <karlarao_at_gmail.com>
>
> An:
>
> oracle-l_at_freelists.org
>
> Datum:
>
> 27.04.2009 13:24
>
> Betreff:
>
> Physical CPU? or multicore?
>
> Gesendet von:
>
> oracle-l-bounce_at_freelists.org
>
> With the release of Intel (Nehalem) 5500 series, which is 45nm and I
> believe also supports multicore and hyperthreading. There are some
> things going on my mind..So from a single socket (Nehalem), quad
> core and HT enabled. You could see 8 processors when you do
cat /proc/cpuinfo
> But, from the performance perspective. Which is better?
> Having 8 physical CPUs? Or Having 1 Physical CPU with quad core and
> HT enabled?
> (Well, we know the license implications of 8 physical CPUs).. :)
> But for the performance engineers and capacity planners. I'd like to
> hear your opinion.
>
> - Karl Arao
> karlarao.wordpress.com
-- http://www.freelists.org/webpage/oracle-l
Received on Mon Apr 27 2009 - 07:54:27 CDT

Original text of this message