Does hyperthreading impact...?

[Johnson184]

Hey guys,
I've got a few questions about what hyperthreading affects for a dual screen setup.

1. Does it make a difference playing a video game on 1st screen while watching bluray on the 2nd screen?

2. Does it make a difference playing video games and music (iTunes) at the same time?

3. Does it make a difference processing video? (Converting big videos from one format to another?)

I'm just trying to figure out what hyperthreading helps. Seems like everyone is suggested that they don't need it. Is it a gimmick that benefits a very small minority (1%)?

 

[Cogman]

1. Yes. But it REALLY depends on the programming that has been done. All single threaded apps take a hit from hyperthreading. However, running multiple single threaded intensive apps (beyond the number of physical cores in the system) and multithreaded apps (that use more threads then physical cores) will see a benefit from it. Essentially, if you have more intensive threads then you have physical cores, then you will see a benefit from enabling hyperthread, If not, then it has a *slight* penalty (Usually not a big issue).

2. Depends on the video game (see post 1). Itunes is not an intensive application (Unless they have some new wizbang DRM scheme that sucks .... Up cpu cylces)

3. Depends on the codec being used. x264, for example, sees a pretty good performance increase due to hyperthreading. xVid, not so much. How effectively the application uses threads is really important to how well hyperthreading works.

In other words, the effects of hyperthreading really depend on the situation it is being put in. A single threaded application, running on its own, will see no benefits from hyperthread (a penalty even).

 

[Ben90]

Unless they have some new wizbang DRM scheme that sucks .... Up cpu cylces

lol'd

Note HTT has nothing to do with the number of screens.

 

[evolucion8]

lol'd

Note HTT has nothing to do with the number of screens.

HTT? Hyper Threading Technology? Hyper Transport Technology?

 

[Scali]

The OS you use can also have impact on how well HT works.
Namely, the thread scheduler needs to be hyperthreading-aware.
Windows 2000 wasn't aware of HT at all, and just assumed it was a regular dualcore.
This led to certain situations where enabling HT would give a performance impact (which led to the reputation that HT gained, and apparently still hasn't lost today).
Windows XP received an update to the scheduler that knows how to avoid these situations. The result was that there was virtually no performance impact in any situation, nothing more than a few percent at most, so no reason to turn it off.

With Windows 7, Microsoft updated the scheduler again, mainly for Core i7. So that probably improves HT performance even more.
I think it's pretty much a non-issue at this point. Hyperthreading is generally always nice to have.

 

[Ben90]

HTT? Hyper Threading Technology? Hyper Transport Technology?

from wikipedia:
"There has been some marketing confusion between the use of HT referring to HyperTransport and the later use of HT to refer to Intel's Hyper-Threading feature on some Pentium 4-based and the newer Nehalem and Westmere-based Intel Core microprocessors. Hyper-Threading is officially known as Hyper-Threading Technology (HTT) or HT Technology. Because of this potential for confusion, the HyperTransport Consortium always uses the written-out form: "HyperTransport.""

 

[Cogman]

The OS you use can also have impact on how well HT works.
Namely, the thread scheduler needs to be hyperthreading-aware.
Windows 2000 wasn't aware of HT at all, and just assumed it was a regular dualcore.
This led to certain situations where enabling HT would give a performance impact (which led to the reputation that HT gained, and apparently still hasn't lost today).
Windows XP received an update to the scheduler that knows how to avoid these situations. The result was that there was virtually no performance impact in any situation, nothing more than a few percent at most, so no reason to turn it off.

With Windows 7, Microsoft updated the scheduler again, mainly for Core i7. So that probably improves HT performance even more.
I think it's pretty much a non-issue at this point. Hyperthreading is generally always nice to have.

Ummm. No

The "Virtual" core and the real core of hyperthreading are identical. A process put on the real or "virtual" core will run at exactly the same speed. The only time this will impact anything is when you have two processes running on the same core at the same time.

The win2000 scheduler, back in the P4 days, had nothing to do with hyperthreadings performance decrease. There was only one core. What was it supposed to do? Ignore the virtual core all together? Where it really had problems was in the server environment. When the system had more then one cpu, win2000 thought of every core as a physical core, and so it would screw things up. This, however, wasn't something a home user of Win2000 would ever really notice. (One CPU, One core, back in the day)

Hyperthreading decreases the speed of single threaded apps because, at the hardware level, it adds an extra layer to executing instructions. This is usually not a big performance decrease, but it is there. (Which, I believe is what I said in my original post)

 

[Scali]

Ummm. No

Why not?

The "Virtual" core and the real core of hyperthreading are identical. A process put on the real or "virtual" core will run at exactly the same speed. The only time this will impact anything is when you have two processes running on the same core at the same time.

Duh, I know this, in fact, I pointed the exact same thing out only a few days ago (many people seem to think that there's one real core and one virtual core for every core with HT).
No need to lecture me.

The win2000 scheduler, back in the P4 days, had nothing to do with hyperthreadings performance decrease. There was only one core. What was it supposed to do? Ignore the virtual core all together? Oh wait, that is what it DID do! So you would get non of the benefits of hyperthreading and all the penalties.

I don't think you quite get it.
You have one core which runs two threads, and as such shares cache and execution resources.
By naively just running random threads as if they were two isolated physical CPUs or cores, you can run into various situations of resource contention, which will decrease performance.

A HT-aware scheduler is aware of the fact that resources are shared, and that sometimes resource contention may occur. It knows some heuristics to detect these situations, and it will take action to avoid these scenarios by distributing threads differently over the cores.
For example, it can choose to run an idle thread on the second core of an SMT pair, or it can try to find a combination of two threads that coexist well together (eg because they share the same caches, or because one of them is not CPU/memory-intensive).

Win2k could still get the benefits of HT, there was just a bit more 'luck' involved.

I think you need to delve a bit deeper into the material here.
Try this paper for example:
http://www.usenix.org/event/usenix05/tech/general/full_papers/short_papers/bulpin/bulpin.pdf

 

[Cogman]

Why not?



Duh, I know this, in fact, I pointed the exact same thing out only a few days ago (many people seem to think that there's one real core and one virtual core for every core with HT).
No need to lecture me.



I don't think you quite get it.
You have one core which runs two threads, and as such shares cache and execution resources.
By naively just running random threads as if they were two isolated physical CPUs or cores, you can run into various situations of resource contention, which will decrease performance.

A HT-aware scheduler is aware of the fact that resources are shared, and that sometimes resource contention may occur. It knows some heuristics to detect these situations, and it will take action to avoid these scenarios by distributing threads differently over the cores.
For example, it can choose to run an idle thread on the second core of an SMT pair, or it can try to find a combination of two threads that coexist well together (eg because they share the same caches, or because one of them is not CPU/memory-intensive).

Win2k could still get the benefits of HT, there was just a bit more 'luck' involved.

I think you need to delve a bit deeper into the material here.
Try this paper for example:
http://www.usenix.org/event/usenix05/tech/general/full_papers/short_papers/bulpin/bulpin.pdf

Eeep, You posted after the edit.

 

[Scali]

Eeep, You posted after the edit.

And so? I don't know what you edited, but it's still wrong.
HT doesn't add an extra layer. It just splits certain resources up 50-50, such as the reorder buffer slots. Cache gets split automatically, because it acts as a shared cache, and the set-associative nature does the rest.
A decent HT-aware scheduler can do its work so well that this sharing of resources has virtually no impact in practical situations, and the difference between HT on and HT off for single-threaded performance is negligible.

 

[Cogman]

And so? I don't know what you edited, but it's still wrong.
HT doesn't add an extra layer. It just splits certain resources up 50-50, such as the reorder buffer slots. Cache gets split automatically, because it acts as a shared cache, and the set-associative nature does the rest.
A decent HT-aware scheduler can do its work so well that this sharing of resources has virtually no impact in practical situations, and the difference between HT on and HT off for single-threaded performance is negligible.

.. How does it split the layers up 50-50, and how does it determine which process gets which resource. That would be the extra layer.

HT isn't a straight 50-50 split. It has its own scheduler and everything on the CPU core. If one thread is using the ALU and the other thread wants to use it as well, the other thread has to wait for the ALU to be freed up. (though, often there are more then one ALUs.. still though)

Now if the machine has a multicored processor, then a hyperthreading aware OS is important. Having the OS schedule one thread per physical core would speed things up significantly.

 

[Scali]

.. How does it split the layers up 50-50, and how does it determine which process gets which resource. That would be the extra layer.

Nope. An extra layer would imply that it is wrapped around the existing layers. In this case some logic is duplicated and exists side-by-side.
The path an instruction travels is no longer or shorter, regardless of whether HT is enabled or not.

HT isn't a straight 50-50 split. It has its own scheduler and everything on the CPU core. If one thread is using the ALU and the other thread wants to use it as well, the other thread has to wait for the ALU to be freed up. (though, often there are more then one ALUs.. still though)

There is no need for that, as the standard ooo-logic already takes care of that, once the instructions are decoded and buffered (there is no more scheduling required than for regular out-of-order superscalar execution).
I suggest you read through the Intel Optimization manual, it describes in detail how the various HT architectures work:
http://www.intel.com/assets/pdf/manual/248966.pdf

2.6.1.2 Partitioned Resources
Several buffers are shared by limiting the use of each logical processor to half the
entries. These are referred to as partitioned resources. Reasons for this partitioning
include:
• Operational fairness
• Permitting the ability to allow operations from one logical processor to bypass
operations of the other logical processor that may have stalled

Because of this hard 50-50 partitioning, load balancing between the two threads is mostly implicit. HT does nothing to explicitly regulate the load balancing.

Now if the machine has a multicored processor, then a hyperthreading aware OS is important. Having the OS schedule one thread per physical core would speed things up significantly.

It makes a lot of difference on a single-core aswell. Various reviews comparing Win2k vs WinXP on early P4HT CPUs concluded this.
See Microsoft's doc on the matter:
http://download.microsoft.com/downl...ae-9272-ff260a9c20e2/Hyper-thread_Windows.doc

The thing is that scheduling one thread per physical core is most certainly NOT the way to speed up things in most cases. If it were, then HT would be pointless by default.

 

[borisvodofsky]

Does it matter???? NOoooooooooooooooooooooooo

That's enough trolling out of you. Please enjoy your vacation.
-ViRGE

 

[NP Complete]

I'd also have to agree with Scali - hyperthreading being enabled should have almost 0 impact on single threaded due to hardware considerations. Any real world impact hyperthreading has on performance is most likely caused due to resource contention due to thread scheduling.

Further, from when I used to work on hardware design at Intel, disabling hyperthreading likely doesn't change the execution path, but merely changes some of the status/reporting registers, and disables some of the hyperthreading control registers. The reason for this is that most Intel hardware is validation constrained, and adding a new execution path likely doubles the validation effort. Unless there's a significant performance or power benefit to having 2 execution paths (there isn't, hyperthreading control logic probably uses very few transistors/gates, meaning minimal power savings, and very little impact to executing timing), the choice would be made to use a single execution path. If you have a choice of launching a bug free chip on time vs a chip with .01% more performance 5 months late, the choice is pretty clear.

 

[NP Complete]

Does it matter???? NOoooooooooooooooooooooooo

Actually, I believe it does matter - if you read the original posters questions, he's wondering if hyperthreading impacts single threaded performance, a very relevant question if he wants to get the most performance possible from his hardware.

The rest of the replies are really trying to discuss whether or not there is a difference, at a fairly technical level.

To address the OPs question:

1. Depends on the game you're running and if you're running a quad core (or better). Most games use ~2 CPUs (some use more, older ones use less), and I bet bluray can also use ~2 CPUs, so in most scenarios there is probably little performance impact with Hyperthreading on vs off. With a 2 core machine, you're more likely to get a performance boost.

2. See answer in #1. It's even less likely to boost performance, as audio uses very few CPU resources.

3. Yes, to a degree. Depends on the video encoding software, and if it's multithreaded.

Hyperthreading isn't a gimmick, but most consumers won't see a large benefit on a quad core system. Hyperthreading really shines on encoding/rendering/scientific workloads, something most typical consumers probably don't use extensively (in which case it becomes a marketing gimmick). It does help out a decent amount on dual core systems.

 

[Edrick]

As we move into the 6-core, 8-core, 12-core CPU world, in my opinion, HT plays much less of a role. I know some people turn off HT on their i7s for multiple reasons. I just purchased an i5 750, instead of a i7 860, because I was not going to use HT anyways. I have always looked at HT as a cheap way to add more "cores" to the P4 CPU back in the day. I was very surprised Intel brought it back with the i7's.

 

[intangir]

As we move into the 6-core, 8-core, 12-core CPU world, in my opinion, HT plays much less of a role. I know some people turn off HT on their i7s for multiple reasons. I just purchased an i5 750, instead of a i7 860, because I was not going to use HT anyways. I have always looked at HT as a cheap way to add more "cores" to the P4 CPU back in the day. I was very surprised Intel brought it back with the i7's.

On the contrary, multithreading (multiple threads per core) is seen as a complement to multicore (multiple cores in one system). They both have advantages and disadvantages, but one tends to benefit in situations where the other is weak. And hyperthreading tends to be more often a benefit in multicore systems because it has more opportunities to find workloads that allow more parallel execution.

http://arstechnica.com/old/content/2002/10/hyperthreading.ars/5

The fact that Intel until now has made use of hyper-threading only in its SMP Xeon line is telling. With hyper-threading's pitfalls, it's perhaps better seen as a compliment to SMP than as a replacement for it. An SMT-aware OS running on an SMP system knows how to schedule processes at least semi-intelligently between both processors so that resource contention is minimized. In such a system SMT functions to alleviate some of the waste of a single-threaded SMP solution by improving the overall execution efficiency of both processors. In the end, I expect SMT to shine mostly in SMP configurations, while those who use it in a single-CPU system will see very mixed, very application-specific results.

 

[Cogman]

Scali, from Microsofts doc.

To take advantage of this performance opportunity, the scheduler in the Windows Server 2003 family and Windows XP has been modified to identify HT processors and to favor dispatching threads onto inactive physical processors wherever possible.

Pretty much EXACTLY what I was trying to say windows XP does. If there is only one physical processor, windows 2000 behaves similarly to windows XP with hyperthreading. XP puts one thread on each physical core first before putting a second thread on the same core.

 

[Scali]

Pretty much EXACTLY what I was trying to say windows XP does. If there is only one physical processor, windows 2000 behaves similarly to windows XP with hyperthreading. XP puts one thread on each physical core first before putting a second thread on the same core.

I'm not sure what you mean with 'physical processor', but as long as HT is involved, they do NOT behave similarly.
It seems you don't understand the basics of HT, namely that the CPU presents itself to the BIOS/OS as a dual CPU system. Therefore, if the OS is multi-CPU aware (like Windows 2000), it will run two threads simultaneously on a HT processor. So there is no specific support required for HT to work in an OS, as long as it can handle multi-CPUs.
XP improves on this by knowing that scheduling on virtual cores has a few caveats because of possible resource contention issues (which would not normally occur on a conventional multi-CPU system, so while most OSes could use HT processors out-of-the-box, in some cases performance was decreased rather than increased when HT was enabled). See the paper that I linked earlier, which talks about this, and heuristics to avoid them.
Windows 7 improves the HT-aware scheduler even further.

 

[Cogman]

Scali, that was a direct quote out of the MS documentation you linked. In other words, XP schedules 1 thread per physical core at first, then doubles up when more thread arrive. In the case of only 1 physical core. XP and 2000 behave the same.

 

[intangir]

XP improves on this by knowing that scheduling on virtual cores has a few caveats because of possible resource contention issues (which would not normally occur on a conventional multi-CPU system, so while most OSes could use HT processors out-of-the-box, in some cases performance was decreased rather than increased when HT was enabled). See the paper that I linked earlier, which talks about this, and heuristics to avoid them.
Windows 7 improves the HT-aware scheduler even further.

So, what impact do these scheduler improvements have when running a single-core system with two logical processors? How would the Windows 7 scheduler function differently than the original Windows 2k scheduler on such a system?

 

[Scali]

Scali, that was a direct quote out of the MS documentation you linked. In other words, XP schedules 1 thread per physical core at first, then doubles up when more thread arrive. In the case of only 1 physical core. XP and 2000 behave the same.

No, you are taking one aspect of the HT-aware scheduler in XP, and then generalize it to be THE scheduler, and conclude that its behaviour is the same as 2000.
I urge you to grab a P4HT system, install 2000 and XP on it, and do various multitasking tests with HT enabled and disabled.
You will see that in Windows 2000 there will be various cases where performance is decreased with HT enabled. The exact same cases in XP will show little or no performance loss in XP with HT enabled, because the scheduler is avoiding them.

It's a shame that I can't google up reviews that demonstrate it anymore, because it was so long ago. But it certainly works that way. Even 'single-threaded' things like games would suffer from HT in Windows 2000 (they are never truly single-threaded, it's just that there aren't many CPU-intensive threads active at a time).

Anyone want to jump in and back me up here?

Edit:
Perhaps this will convince you:
http://www.intel.com/support/processors/sb/cs-017343.htm

Microsoft Windows* Operating System Desktop Based PCs
The following desktop operating systems include optimizations for HT Technology and are currently eligible to carry the new Intel® Pentium® 4 Processor with HT Technology logo:

Microsoft Windows* XP Professional Edition
Microsoft Windows* XP Home Edition
Microsoft Windows* Vista Home Basic
Microsoft Windows* Vista Home Premium
Microsoft Windows* Vista Home Ultimate
Microsoft Windows* Vista Home Business

The following desktop operating systems are not recommended for use with Hyper-Threading Technology. If you are using one of the following desktop operating systems, it is advised that you should disable Hyper-Threading Technology in the system BIOS Setup program:
Microsoft Windows* 2000 (all versions)
Microsoft Windows NT* 4.0
Microsoft Windows* Me
Microsoft Windows* 98
Microsoft Windows* 98 SE

Intel advises to disable HT for Windows 2000, but not for XP.

 

[Scali]

So, what impact do these scheduler improvements have when running a single-core system with two logical processors? How would the Windows 7 scheduler function differently than the original Windows 2k scheduler on such a system?

Read the paper I linked.

 

[intangir]

Read the paper I linked.

I did. All it said was that the Win2k scheduler would attempt to schedule the lower half of the numbered logical processors before the higher half. And that a HyperThread-aware scheduler would prefer scheduling processes on free physical processors before putting two processes on the same physical processor.

That's the only difference, and on a 2-logical-processor system, they end up functioning the same.

 

[Scali]

I did. All it said was that the Win2k scheduler would attempt to schedule the lower half of the numbered logical processors before the higher half. And that a HyperThread-aware scheduler would prefer scheduling processes on free physical processors before putting two processes on the same physical processor.

I was talking about this paper:
http://www.usenix.org/event/usenix05/tech/general/full_papers/short_papers/bulpin/bulpin.pdf

That's the only difference, and on a 2-logical-processor system, they end up functioning the same.

Incorrect.
If they functioned the same, Intel wouldn't have to recommend people to turn HT off for Windows 2000.

I'm surprised you guys are so adamant, you haven't even researched the topic properly (the MS paper is clearly not the full technical info. If you google around, you'll find more).