Re: Hyperthreading - Oracle license

From: Alex Fatkulin <afatkulin_at_gmail.com>
Date: Fri, 11 Jan 2013 14:42:02 -0500
Message-ID: <CAMVw97LK=63cpHMO23roqT+3TLhF5vWsmCYYsnkFek3Jap7SCA_at_mail.gmail.com>



I don't read the tone of the note as "recommends", more like saying that it's fine to have it 2x and "potentially providing greater throughput and improved performance".

The goal of HT was to provide better throughput when exceeding physical number of CPUs compared to the case where HT is turned off by utilizing the fact that two threads can archive better pipeline utilization by filling in "voids" left by the other thread. This is why HT provides a lot of benefits on the "branchy" code where execution pipeline is having a hard time keeping efficiency up.

Modern Intel CPUs (SandyBridge) got very sophisticated in how they manage HT. Where previous generations required static partitioning of some execution resources for each thread (which sometimes lead to a lower per-thread performance with HT enabled) SB does a lot of allocation dynamically depending on the thread workload.

On SUN (Oracle) SMT the cpu_count reported by the OS does lead to other calculated parameters (parallel_max_servers, etc.) to be really on a high side though.

On Thu, Jan 10, 2013 at 5:30 PM, Rich Jesse <rjoralist2_at_society.servebeer.com> wrote:
> Mark writes:
>
>> Actually, a quick MOS search, and Oracle specifically recommends staying w/
>> the "doubled" count for cpu_count.
>>
>> See Doc ID 289870.1
>
> I saw that, too, and I'm calling "BS" on the lack of evidence, empirical or
> otherwise. Unless it can be claimed that turning HT on gives one at or near
> a 100% gain in CPU power, it stands to reason that Oracle cannot consume at
> or near an additional 100%. And I'm reasonably certain that no one is
> advocating HT as giving anywhere near another the performance of another
> core.
>

-- 
Alex Fatkulin,
http://afatkulin.blogspot.com

Enkitec,
http://www.enkitec.com
--
http://www.freelists.org/webpage/oracle-l
Received on Fri Jan 11 2013 - 20:42:02 CET

Original text of this message