angryswede
Member
i know it acts like a virtual dual processor, and the thread has to think it has sole presence in the CPU, but can someone elaborate?
-
We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.
hyperthreading
- Thread starter angryswede
- Start date
I would suggest you let xitlabs elaborate if you want a really detailed explanation. You are pre-warned that this is a very technical look. Pages 23-28 detail hyperthreading http://www.xbitlabs.com/articles/cpu/display/netburst-1_23.html
This page from Anand should give you a basic walkthrough if thats what you are looking for. http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=1746&p=4
Edit: Found one more from Anand, fairly detailed, though not too technical. Based on very early data. http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=1576&p=1
This page from Anand should give you a basic walkthrough if thats what you are looking for. http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=1746&p=4
Edit: Found one more from Anand, fairly detailed, though not too technical. Based on very early data. http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=1576&p=1
In layman's terms, Hyperthreading allows the processor to start 2 discrete threads, even though it doesn't have the resources to process them at the same time.
Think of it like a road...it starts as double lane and merges into a single lane as opposed to just a single lane. The major advantage is that it bypasses the Windows scheduler (sort of like the traffic cop) for 2 programs running simultaneously. This doesn't make the traffic faster, but it sure is a heck of a lot smoother!
Jeff7181
Lifer
I recommend reading in the following order, but you may skip directly to the Multithreading, Superthreading, and Hyperthreading article.
Pipelining Part 1
Pipelining Part 2
Multithreading, Superthreading, and Hyperthreading
Pipelining Part 1
Pipelining Part 2
Multithreading, Superthreading, and Hyperthreading
angryswede
Member
As I, and others have stated before, Hyperthreading's primary purpose is to allow a more efficient usage of a processor's executions units.
The Athlon is a three-issue core.
That means in order to achieve an IPC close to its theoretical maximum, it must find three instructions it can execute in parallel, per clock cycle.
If a particular thread has a high degree of data dependency, then there are going to be pipeline bubbles forming, since many instructions depend on the results of previous instructions.
With Hyperthreading, the P4 can pick instructions from an independent thread, or alternatively send that thread to the FPUs, if that thread is comprised of floating-point code.
The Athlon, being a wider-issue core than the P4, would actually benefit atleast as much as the P4 has when executing multithreaded code, and probably more.
The other benefit of Hyperthreading is really more of a fix of Windows' scheduler.
Hyperthreading does not mask the negative impact of a deeper pipeline when running single-threaded code. If you're running a game for example, and the branch predictor mispredicts, how is the resulting performance impact going to be negated by continually running a thread from an independent program?
The benefit here is that it allows two independent threads to run uninterrupted.
The problem with pre-emptive multitasking is that when running two demanding applications, the scheduler continually swtiches between them, giving priority to one. The performance impact comes in the form of memory access. Memory is slow in comparison to the time it takes to fill even Prescott's pipeline.
So when a thread starts fetching from memory, there is a huge delay, relatively speaking. Now if these two threads are continually swapping, then the impact in terms of wasted clock cycles resulting from the associated memory access is what causes poor multitasking performance in non-SMT designs.
The P4 gains more in this instance than would the Athlon 64, purely because the A64 has such a fast memory interface.
It has nothing to do with the P4's pipeline.There is certainly no perceptible delay as the pipeline fills.
Taking a 3.0GHz Prescott as an example, the time it takes for the pipeline to fill and hence achieve an instruction (or two) per clock is shown below:
Instruction Latency = TP
Where T is the period (the duration of the clock cycle),
And P is the number of pipeline stages.
Instruction Latency = 3e-09 X 31 = 10ns. (Rounded)
So, the time it takes to fill a 3.0GHz Prescott's pipeline is a whopping 10ns.
If you want an idea of how quick this is, this is much quicker than you can blink. Much, much quicker, and also alot quicker than the delay caused in going to main memory.
For smooth multitasking, you need either a very fast memory interface (Athlon 64), or the ability to process two threads simultaneously without having to continually fetch them from memory (SMT).
The Athlon is a three-issue core.
That means in order to achieve an IPC close to its theoretical maximum, it must find three instructions it can execute in parallel, per clock cycle.
If a particular thread has a high degree of data dependency, then there are going to be pipeline bubbles forming, since many instructions depend on the results of previous instructions.
With Hyperthreading, the P4 can pick instructions from an independent thread, or alternatively send that thread to the FPUs, if that thread is comprised of floating-point code.
The Athlon, being a wider-issue core than the P4, would actually benefit atleast as much as the P4 has when executing multithreaded code, and probably more.
The other benefit of Hyperthreading is really more of a fix of Windows' scheduler.
Hyperthreading does not mask the negative impact of a deeper pipeline when running single-threaded code. If you're running a game for example, and the branch predictor mispredicts, how is the resulting performance impact going to be negated by continually running a thread from an independent program?
The benefit here is that it allows two independent threads to run uninterrupted.
The problem with pre-emptive multitasking is that when running two demanding applications, the scheduler continually swtiches between them, giving priority to one. The performance impact comes in the form of memory access. Memory is slow in comparison to the time it takes to fill even Prescott's pipeline.
So when a thread starts fetching from memory, there is a huge delay, relatively speaking. Now if these two threads are continually swapping, then the impact in terms of wasted clock cycles resulting from the associated memory access is what causes poor multitasking performance in non-SMT designs.
The P4 gains more in this instance than would the Athlon 64, purely because the A64 has such a fast memory interface.
It has nothing to do with the P4's pipeline.There is certainly no perceptible delay as the pipeline fills.
Taking a 3.0GHz Prescott as an example, the time it takes for the pipeline to fill and hence achieve an instruction (or two) per clock is shown below:
Instruction Latency = TP
Where T is the period (the duration of the clock cycle),
And P is the number of pipeline stages.
Instruction Latency = 3e-09 X 31 = 10ns. (Rounded)
So, the time it takes to fill a 3.0GHz Prescott's pipeline is a whopping 10ns.
If you want an idea of how quick this is, this is much quicker than you can blink. Much, much quicker, and also alot quicker than the delay caused in going to main memory.
For smooth multitasking, you need either a very fast memory interface (Athlon 64), or the ability to process two threads simultaneously without having to continually fetch them from memory (SMT).
Jeff7181
Lifer
No. IBM uses Hyperthreading in some of their chips and they have a short pipeline just like the Athlon 64. However, the pipeline is very wide, so it benefits from being able to run two threads simultaneously. I'm sure AMD has weighed the benefits, and obviously have decided it's not worth the cost to them. I suspect it's not so much due to the shorter pipeline, but rather due to the fact that the A64 is a well rounded processor... the pipeline isn't rediculously long or rediculously wide.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 25K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 24K
-
-
