Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Next AMD FX-8120 update



> 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.

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
>
>
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org