How Hyperthreading works

[nobly]

Hi All,

Need to clarify a Hyperthreading question here:
If I have a P4 w/ Hyperthreading, does Hyperthreading only apply to 1 process or can it apply to multiple processes?

Does 1 multi-threaded process only use Hyperthreading?
Or can 2 individual processes gain with Hyperthreading? Say 1 intensive process uses the CPU most, can the 2nd process (Firefox or something) use the CPU at the same time?

It was my understanding that it effectively looked like a 2-CPU system, but multiple processes could use the CPU at the same time, given that the Hyperthreading conditions were met.

I've seen articles both ways, so if you can find something that's on a reputable site, I'd ask you to link it.

Thanks!

 

[nobly]

I found this on Tom's Hardware, but I need to determine if its absolutely correct:

"That includes high-scale transaction-oriented computing, financial, engineering and scientific digital media, gaming, and special effects applications, or in short, any application that runs the CPU at full throttle with more than one thread."
http://www.tomshardware.com/2002/12/27/hyperthreading_threads_its_way_into_application/

I mean, that obviously would help the application, but what about other background processes? Would Hyperthreading be able to give tasks to the unused CPU resources while running an intensive app?

 

[dvdpiddy]

go pm mike he knows the most about procs on these forumz

 

[joset]

If you care to have a peek:


http://arstechnica.com/articles/paedia/cpu/hyperthreading.ars


Cheers!

 

[dvdpiddy]

If you care to have a peek:


http://arstechnica.com/articles/paedia/cpu/hyperthreading.ars


Cheers!

thats good too

 

[nobly]

If you care to have a peek:
http://arstechnica.com/articles/paedia/cpu/hyperthreading.ars
Cheers!

First off, thanks a ton for the link!

Now... This would suggest that multiple processes can use Hyperthreading, just not to its fullest extent.
"Intel's next major IA-32 processor release, codenamed Prescott, will include a feature called simultaneous multithreading (SMT), also known as hyper-threading."

"SMT, in a nutshell, allows the CPU to do what most users think it's doing anyway: run more than one program at the same time. "

"As with SMP, this will ultimately depend on the applications themselves, since multithreaded apps will benefit more from hyper-threading than single-threaded ones. Of course, unlike with SMP there will be an added twist in that real-world performance won't just depend on the applications but on the specific mix of applications being used."

Hyperthreading can run multiple threads at once and this article seemed to suggest that since the CPU itself does not know or care where these threads came from (whether or not the same process spawned them), running multiple processes is possible.

Does that sound right?
Thanks again!

 

[psyno]

No part of the hardware says it can't be executing threads simultaneously from unrelated processes. It's up to the OS scheduler, which also likely wouldn't impose such a restriction.

 

[joset]

"Intel's next major IA-32 processor release, codenamed Prescott, will include a feature called simultaneous multithreading (SMT), also known as hyper-threading."

"SMT, in a nutshell, allows the CPU to do what most users think it's doing anyway: run more than one program at the same time. "

"As with SMP, this will ultimately depend on the applications themselves, since multithreaded apps will benefit more from hyper-threading than single-threaded ones. Of course, unlike with SMP there will be an added twist in that real-world performance won't just depend on the applications but on the specific mix of applications being used."

Hyperthreading can run multiple threads at once and this article seemed to suggest that since the CPU itself does not know or care where these threads came from (whether or not the same process spawned them), running multiple processes is possible.

Does that sound right?

Some corrections to the (2002) article (and mind this: the author is a very respected computer engineer... but, everybody makes mistakes, now & then.):

1. Intel IA-32 stands for Intel Architecture 32-bits; however, none of Intel processors - apart Itanium - use IA-32. From the first P4 and up until now, only "NetBurst" x86 architecture was used by Intel, until Dempsey/Conroe/Merom are released (IA-32 is a sub-set of IA-64 or EPIC, which was implemented to allow Itanium to run 32-bit applications but was recently abandoned.);

2. "As with SMP, this will ultimately depend on the applications themselves, (...)".

I guess this and psyno's reply do answer your question.
Also, if you've gone through the full article, you must have noticed that "Hypertheading" is a logical, rather than, a physical process (uses the same resources alternately, which makes it hardly SMT...).


Cheers!

 

[joset]

Fanboys...


No, most of the high-end technologies do come from the mainframe space.
Although Intel's "Hyperthreading" is an Intel patent, similar 'virtualization' (better call it logical partitioning) technologies already existed, for instance, in IBM mainframe architectures... a bit like AMD's "HyperTransport", inherited from DEC Alpha's...

 

[joset]

APOLOGY

Quote:
"Intel's next major IA-32 processor release, codenamed Prescott, will include a feature called simultaneous multithreading (SMT), also known as hyper-threading."


http://arstechnica.com/articles/paedia/cpu/hyperthreading.ars


«Some corrections to the (2002) article (and mind this: the author is a very respected computer engineer... but, everybody makes mistakes, now & then.):

1. Intel IA-32 stands for Intel Architecture 32-bits; however, none of Intel processors - apart Itanium - use IA-32. From the first P4 and up until now, only "NetBurst" x86 architecture was used by Intel, until Dempsey/Conroe/Merom are released (IA-32 is a sub-set of IA-64 or EPIC, which was implemented to allow Itanium to run 32-bit applications but was recently abandoned.)»

Scratch this.

I must apologize everyone in this thread & the article's author, in particular, for my mistake.

IA-32 (or x86) is the architecture beneath all Intel 32-bit architectures:

ftp://download.intel.com/design/Pentium4/manuals/24896612.pdf

After all, we ALL make mistakes.


Cheers!

 

[concunam2005]

hi friend,
i just wonder that P4 506 has a indentical architect with the other P4's HTT.So can we activate HTT in P4 506?. because when i use PCMark 2005, it said that my P4 has HTT but it isn't activatied....So anysoftware can do this stuff?...
Thanks

 

[joset]

You must activate HT in the BIOS.


Cheers!

 

[bront]

From what I've seen, HT on a dual core CPU doesn't help much, and in fact hurt performance over just a standard dual core. I'm not sure if this is because of how Intel implemented it or not however.

 

[hashv2f16]

I mean, that obviously would help the application, but what about other background processes? Would Hyperthreading be able to give tasks to the unused CPU resources while running an intensive app?

that's the ticket

 

[joset]

From what I've seen, HT on a dual core CPU doesn't help much, and in fact hurt performance over just a standard dual core. I'm not sure if this is because of how Intel implemented it or not however.

True, HT often hampers performance, even in dual-core processors, mostly because most software is (not yet) multithreading compiled. Also note that, even physical dual-cores do suffer from this software issues; that's why, more often than not, single cores w/identical frequency outperform dual-cores, in non-threaded applications.
Moreover, due to its logical partitioning nature, "Hyperthreading" is an alternating process, where threads share the available common physical execution units, increasing latency.

Cheers!

 

[nobly]

I find that HT does actually help overall. The issue at hand is benchmarking, but in truth, what application can you use to apply HT to?
HT is NOT dual-core or dual processor. It utilizes 'unused' areas in the processor to execute other commands on different threads.

I agree w/ joset, most software does not take advantage of multi-logical processors.

But after enabling HT, here are my observations:
1) The system is more responsive when doing CPU intensive applications (single threaded) - I find that this is because the unused parts of the CPU are being used now. The application suffers minimally in execution time, given that you don't do any other CPU intensive stuff.
2) Its faster when you're running 2 CPU intensive apps. One app might be slower than if it were done w/o HT enabled, but there is a net time gain overall. I've tested this.
3) HT gives the performance gain when 2 threads or processes do not depend on each other for data. If one thread is waiting for the other for processing data, its going to be slow. But if the threads don't need anything from each other, its just contention for CPU areas - but this isn't altogether bad, since 100% of the CPU is being used. Contention means that two threads are waiting for 1 area of the CPU, but once the 1st thread is done, the 2nd thread goes through, while the 1st thread uses other parts of the CPU. So overall its better, as long as the app is intensive enough to let the gains overcome the HT overhead. If I run 2 instances of an identical app, I see a significant performance increase - almost 20% time saved. I've reproduced that whenever I turn HT on.

So IMO, HT gains/losses depends on 1) the application you are running, 2) the other applications that are running, 3) how intensive the app is for the CPU, and 4) how accurately you are able to test it (and retest it).

 

[joset]

HT is NOT dual-core or dual processor. It utilizes 'unused' areas in the processor to execute other commands on different threads.


But after enabling HT, here are my observations:
1) The system is more responsive when doing CPU intensive applications (single threaded) - I find that this is because the unused parts of the CPU are being used now. The application suffers minimally in execution time, given that you don't do any other CPU intensive stuff.

Technically, HyperThreading is not really a SMT process (Simultaneous Multi-Threading), since it's not... well, simultaneous; it's alternate. The issue common to [all] SMT is that both OS & the CPU's back-end units, must "search" for instruction extraction (from threads) to execute in "parallel".
For one, there are always processes running in the background which keep the CPU busy; however, 'running' & 'executing', are different matters. Unless for multi-threaded compiled applications, HyperThreading is fine for "simultaneous multi-tasking" (again, that's also why a single core, at the same frequency, beats a dual-core in single-threaded apps.).

In real-world usage, however, there are a lot of other factors to take into account which makes my "technical" argument purely theoretical.


Cheers!

 

[psyno]

Technically, HyperThreading is not really a SMT process (Simultaneous Multi-Threading), since it's not... well, simultaneous; it's alternate. The issue common to [all] SMT is that both OS & the CPU's back-end units, must "search" for instruction extraction (from threads) to execute in "parallel".

Er, actually this is incorrect, on two accounts.

First, Intel's HTT actually is SMT and not alternating. Google Intel's site for HTT/SMT papers...

Second, the OS actually knows nothing about SMT and does nothing special to help it along. It definitely doesn't try to schedule threads based on their instructions to take advantage of the hardware. I'm not sure I would say that the hardware searches for the parallelism either... it's just kind of there.

 

[joset]

:

Technically, HyperThreading is not really a SMT process (Simultaneous Multi-Threading), since it's not... well, simultaneous; it's alternate. The issue common to [all] SMT is that both OS & the CPU's back-end units, must "search" for instruction extraction (from threads) to execute in "parallel".

Er, actually this is incorrect, on two accounts.

First, Intel's HTT actually is SMT and not alternating. Google Intel's site for HTT/SMT papers...

Second, the OS actually knows nothing about SMT and does nothing special to help it along. It definitely doesn't try to schedule threads based on their instructions to take advantage of the hardware. I'm not sure I would say that the hardware searches for the parallelism either... it's just kind of there.

Actually, Hyperthreading works more like this: Software wise, the OS must be SMT-aware, i.e., must concede 'time-slices' to each thread (consider two threads) to run in "parallel". Of course, the time-slices the OS concedes must be short enough for the user not noticing them. In a non-SMT-aware OS (like, say, Win98), you still can use the extra Hyperthreading hardware resources, but not for Simultaneous Multi-Threading; instead, they'll be used - only - for simultaneous multi-tasking.

Hardware wise, an Hyperthreading architecture uses both physical & logical resources to simulate true-SMT. Hyperthreading implementation, relies upon three basic computing assumptions: Replication, Partitioning & Sharing. I'll not go into al of them, but the last, Sharing.

As it's implied, sharing allows the same resources to be used by (the two) threads, such as cache, some registers and, mainly, the execution units. In a true (dual-core or dual-processor - SMP) SMT configuration, two threads can be run - simultaneously - since they're using independent pipelines; with Hyperthreading, they must share the execution pipeline (intructions are interleaved) at high frequencies, in order to seem... well, simultaneous!

That's why Hyperthreading is not a true-SMT process; otherwise, it would probably be simply called... SMT.

Post Scriptum: in an ideal model of SMT, both the hardware & the software would be utterly senseless towards execution. 'Things' would just run &... execute... & store... 'Things' just don't work that way and, besides, it would leave the programmer completely out of the picture, cancelling any chance to access the programmable units...


Cheers!

 

[psyno]

Actually, Hyperthreading works more like this: Software wise, the OS must be SMT-aware, i.e., must concede 'time-slices' to each thread (consider two threads) to run in "parallel". Of course, the time-slices the OS concedes must be short enough for the user not noticing them. In a non-SMT-aware OS (like, say, Win98), you still can use the extra Hyperthreading hardware resources, but not for Simultaneous Multi-Threading; instead, they'll be used - only - for simultaneous multi-tasking.

What you're saying about time slices just isn't SMT. Sure, that's how an OS generally breaks up tasks in a multi-tasking operating system, but it just doesn't have a lot to do with SMT. All an operating system needs to do to support HTT (and more generally SMT) is support SMP. That's really it.

As it's implied, sharing allows the same resources to be used by (the two) threads, such as cache, some registers and, mainly, the execution units. In a true (dual-core or dual-processor - SMP) SMT configuration, two threads can be run - simultaneously - since they're using independent pipelines; with Hyperthreading, they must share the execution pipeline (intructions are interleaved) at high frequencies, in order to seem... well, simultaneous!

That's why Hyperthreading is not a true-SMT process; otherwise, it would probably be simply called... SMT.

This is only partially true, and HTT actually is called SMT (only SMT isn't a term Intel can trademark...). It's true that if both threads want to fetch or both want to decode, then they're alternated at that point in the pipeline. But that's about it. The bottom line is that multiple threads execute simultaneously on the functional units, and thus HTT really is SMT. The schedulers could hardly care less where the instructions come from, and issue multiple instructions per cycle from either or both threads.

If you don't agree with my account of how HTT actually works, try here: http://www.intel.com/technology/itj/2002/volume06issue01/vol6iss1_hyper_threading_technology.pdf

If you don't agree with my account of what SMT actually is, try here: http://www.cs.washington.edu/research/smt/papers/ISCA95.ps
(and more generally, here: http://www.cs.washington.edu/research/smt/ )

Cheers!

Cheers!

 

[joset]

Hi!
It's been a while since I've read Intel's white papers on Hyper-Threading (not an engineer, though).

First off, it's nice to have someone with whom to have a coherent (!) chat on these matters without... well, to put it mildly, having to go through argumentative imbecility. On the other hand, earnest ignorance is not to blame and I hope to be able to contribute to this thread's objective.

As for Hyper-Threading and your suggestive links, I'll give it a re-read and get back in here, asap.


Edit:

I'm referring to "argumentative imbecility" in other threads, not this one.

Cheers!

 

[joefriday]

INTEL'S OFFICIAL TECHNICAL EXPLANATION:

How does hyperthreading work? How's positraction in a plymouth work.....


IT JUST DOES!!!

 

[pmr]

Just for the record. Didn´t u see this?
http://www.tomshardware.com/site/download_submit.html?id=5