[Discuss] Next AMD FX-8120 update

[gaf at blu.org (Jerry Feldman)]

On 03/18/2012 06:59 PM, markw at mohawksoft.com wrote:
>> On 03/18/2012 12:02 PM, Richard Pieri wrote:
>>> What you will typically find is that if your threads are CPU bound then
>>> you will see better performance over the long term with HT disabled.
>>> The reason is that the phantom CPUs that HT provides need to share cache
>>> and memory bandwidth and there is some extra switching overhead.  The
>>> upshot is that if you have 1 CPU with 2 HT threads and 4 CPU-bound jobs
>>> to run, the total time to run all 4 jobs will be less with HT disabled.
>>> As an aside for anyone running a Condor pool, disabling HT is
>>> recommended for this reason.
>>>
>>> On the other hand, if you are not CPU-bound across all of your threads,
>>> or in environments where concurrency is more important than throughput,
>>> then HT may be a win.
>>>
>>> AMD's Bulldozer architecture has less resource contention than Intel's
>>> HT implementations (less overhead) but two threads on 1 core still have
>>> to share some resources and you will usually see results similar to what
>>> I described.
>> In Toronto they always turn off HT. I ran a quick test and found that
>> the RiskWatch application runs better with no HT. There is certainly
>> some benefit to HT under some circumstances.
> The problem isn't with hyperthreads per se' it is a problem with system
> schedulers not knowing the difference or how to use them. Hyperthreads are
> sort of a micro-NUMA environment. Sometimes, it is best to put a HT
> semi-core to sleep instead of using it because there is no appropriate job
> for it to run and running another job would affect its peer.
This is true. For our products, HT tends to reduce performance, but for
some situations, HT tends to improve performance.  I would still be
interested in running a benchmark with HT turned off at work, just to
compare the Intel processors. I know there is considerable differences.

>
> One of the things I was concerned about the FX-8120 was the shared
> resources of the cores. So far it doesn't seem too bad. Even though core
> pairs share a numeric processor and some caching, they seem to schedule
> fairly well independently.
>
> So, like I said, they aren't truly full cores, but they don't seem
> similarly limited.
>
>


-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90