Even in the case of the quad HT should be called a tie or a win and not a regression; an increase in minimums can often indicate less stuttering, which is a real positive. The regression we see so often in hexacores is likely more due to OS scheduler limitations than anything to do with the CPU, of course the net result is still the same, I have HT off on my 5820K because of this.
That is an ironic reply considering that the benefits from HT comes in large part from the schedulers (both the CPU's and the OS'es) If HT were to claim a credit for performance gains which rely on the schedulers, then it should own up to the negatives caused by the schedulers as well.
Or with HT,since basically it doubles cores as far as the cpu is concerned,the cpu just doesn't see enough cpu usage to raise it's turbo clocks...
What HT does is filling underutilized data pipeline of a core by tricking the OS into thinking there are more resources (e.g. another core that in fact does not exists) than there actually are. Depending on the workload and the efficiency of application and the scheduler, there can be benefits and drawbacks. Think of it like a hair dresser who has an appointment every hour. She normally takes care of one customer every hour. But every few customers there comes one with a short hair who only needs trimming, and it takes only 15 minutes or so to do her/his hair. If that happens she will be done with that customer in 15 minutes and is free for 45 minutes, and if there are another customer or two who needs trimming she can do those customers' hair before her next appointment shows up.
As illustrated in this crude analogy, you can see that indeed there are scenarios in which the hair dresser can do more work than normally expected. But certain conditions have to be met. In her case: A customer with a lesser need for care than usual, a customer with a similarly lesser need, and the latter customer should be there when you are finished with the former so that she will not break her next appointment. If she miscalculates the time needed for each customers or some customers do not show up in time frame she is expecting, then other customers might have to wait past their appointment. (causing great anger and resentment in them)
HT fools the OS into believing there are two "logical" or "virtual" cores when there is one physical core. When that happens the OS will attempt to schedule two threads, and the second thread will be waiting in a state where it can be immediately worked on as soon as the first thread is done or stalled (e.g. needs to fetch new data). As you can imagine the potential gains or losses are highly dependent on a given situation as our hair dresser's gains/losses.
Yes but with HT on, threads might be spread too far and between (so to speak) for a single core to have full load, especially if the GPU can't handle it's load(maxes out under the load before the/a cpu core can max out) .
I think you have it backwards. Spreading the threads evenly to different physical cores, assuming they can be spread, is almost always the best practice for performance. Imagine a scenario where the OS schedule two threads into one physical core thinking there are two cores because of HT, while leaving an actual physical core idle. This actually happens a lot on desktop, especially in games. Bulldozer had a similar problem due to its integer units sharing a floating-point unit within a module: the OS would assign threads 1/2 on module 0, and threads 3/4 on module 1. On a 4 module / 8 thread CPU that meant the 4 threads had to fight for 2 modules' 2 floating-point units while leaving the other two modules idle. The performance hit was naturally enormous. An ideal practice for performance is assigning threads 1, 2, 3, 4 on modules 0, 1, 2, 3 separately so that each thread is given full resource of the integer unit and the floating-point unit in a module.
Facebook
Twitter