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 |
> 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 | |
We also thank MIT for the use of their facilities. |