This web page disucsses the hyper-threading article I wrote that was published in MSDN Magazine June 2005.
The full text of the article is available on the MSDN Magazine website.
I will publish a hyper-threading FAQs - for article (and other hyperthreading) questions , email me at yaniv @yanivpessach.com .
Hyperthreading improves CPU efficiency (and application performance) by allowing the processor to execute two 'instruction steams' concurrently. To take advantage of those two instruction streams, at least two threads must be in the 'running' state; each would be allocated to a different 'instruction stream' and they will execute concurrently, as far as the operating system is concerned. It is almost accurate to say that, as far as the operating system is concerned, each executes on a separate logical CPU, and the system does not know that these logical CPUs share most of their hardware.
coming here soon: discussion of the performance results of the article samples on various hyper-threading configuration.
Article FAQs
Q: Why in your opinion is hyperthreading so improtant?
A: Because it is deployed everywhere.
For the first time, home computers have a feature, hyperthreading, that prefers well written, scalable applications. Once a developer optimizes his code for more than one (logical) CPUs, scaling for more CPUs is just a matter of degree.
Ican see, sometime in the visible future, hyper-threading getting past the '2 logical CPUs' mark. And multi-core CPUs, each core also supporting hyper-threading. And other similar parallelizations.And those hardware features would only sell to the degree that existing applications benefit from them. It has been a 'chicken and egg' problem for a long time - but with the introduction of hyperthreading on desktop machines, developers now have the incentive to make their applications scale, which would in turn fuel the entire 'parallelization' cycle.
The future of performance might very well be dominated by careful multiprocessing, and not simply by local code optimization.
Q: Why doesn't hyperthreading simply double my performance like a dual-CPU would?
A: "I may suffer from multiple personality, but I still don't code twice as fast"
More accurately, since the two 'logical CPUs' share most parts of the one physical CPU, the gain expected is only from the increased efficiency when hyper-threading is introduced. This gain can be expected to be 20%-30%; at most, some applications can show 40% performance improvement.
Incidentally, introducing a second physical CPU will not double performance either, due to increased need of locking and other inefficiencies.
For example, when I measured timing for executing (in a tight loop) 'Interlocked.Increment' (or InterlockIncrement, or the assembler LOCK INC instruction) on a single proc (no hyperthreading) vs. a dual proc (no hyperthreading) machine, the results show an order to two orders of magnitude slower on a multi-proc machine (since the two CPUs need to be coordinated). Still, many *cpu-bound* multi-threaded applications would show around 90% improvement when a second CPU is introduced.
Q: Would running my code on a a hyperthreaded machine discover all the concurrency bugs that running it on a true dual-proc machine would?
A: No.
It is true, as my article outlines, that many multithreading bugs that are hard to reproduce on a single-processor machine would show up when running your application on a hyper-threaded machine. But the sequence and timing of code execution is different between true multiproc machines and hyper-threaded machines. To be on the safe side, you need to test your application on both.
Q: A developer in my team asked for a dual proc machine, but I gave him a hyper-threaded machine instead. Why is he unhappy?
A: Hyper-threaded CPUs are not as fast as multiple physical CPUs.
Q: So how *should* I detect hyper-threading from .NET code, especially on Windows XP?
A: The article mentioned the Windows API Call GetLogicalProcessorInformation, which is not supported on XP.
While there is no way to detect HT from C# on XP, which would require assembler call to the CPUID instruction, Intel provides this code sample that (using C++, which does allow inline assembly) detects Hyper-threading. This code would work on both XP and Windows 2000/2003.
Q: Did you hear about a hyper-threading inherent security flaw?
A: I have read the article at http://www.daemonology.net/papers/htt.pdf ; it suggests a 'timing' attack on cryptographic operations executed from a seperate process running on the same machine.
It is not clear whether this attack is practicle under Windows (the only examples were FreeBSD and other Unix variations) but at any rate it should not impact how an application developer would structure their code; If this is an issue, this should be resolved by chip designers and cryptographic library providers.
As more information becomes available, I'll update this page.
More Useful links:
Identifying Hyper-Threading: http://www.intel.com/cd/ids/developer/asmo-na/eng/212489.htm?page=3
Cache Blocking on .NET: Improve performance http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/threading/implementation/170317.htm
cache blocking on hyper-threaded machines: http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/threading/implementation/20461.htm
Hyper-threading tutorial: http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/threading/implementation/20461.htm
Thread priority and hyper-threading: http://www.intel.com/cd/ids/developer/asmo-na/eng/180218.htm?page=2
Develop multi-threaded applications using .NET http://www.intel.com/cd/ids/developer/asmo-na/eng/newsletter/20463.htm?page=4
The full text of the article is available on the MSDN Magazine website.
I will publish a hyper-threading FAQs - for article (and other hyperthreading) questions , email me at yaniv @yanivpessach.com .
Hyperthreading improves CPU efficiency (and application performance) by allowing the processor to execute two 'instruction steams' concurrently. To take advantage of those two instruction streams, at least two threads must be in the 'running' state; each would be allocated to a different 'instruction stream' and they will execute concurrently, as far as the operating system is concerned. It is almost accurate to say that, as far as the operating system is concerned, each executes on a separate logical CPU, and the system does not know that these logical CPUs share most of their hardware.
coming here soon: discussion of the performance results of the article samples on various hyper-threading configuration.
Article FAQs
Q: Why in your opinion is hyperthreading so improtant?
A: Because it is deployed everywhere.
For the first time, home computers have a feature, hyperthreading, that prefers well written, scalable applications. Once a developer optimizes his code for more than one (logical) CPUs, scaling for more CPUs is just a matter of degree.
Ican see, sometime in the visible future, hyper-threading getting past the '2 logical CPUs' mark. And multi-core CPUs, each core also supporting hyper-threading. And other similar parallelizations.And those hardware features would only sell to the degree that existing applications benefit from them. It has been a 'chicken and egg' problem for a long time - but with the introduction of hyperthreading on desktop machines, developers now have the incentive to make their applications scale, which would in turn fuel the entire 'parallelization' cycle.
The future of performance might very well be dominated by careful multiprocessing, and not simply by local code optimization.
Q: Why doesn't hyperthreading simply double my performance like a dual-CPU would?
A: "I may suffer from multiple personality, but I still don't code twice as fast"
More accurately, since the two 'logical CPUs' share most parts of the one physical CPU, the gain expected is only from the increased efficiency when hyper-threading is introduced. This gain can be expected to be 20%-30%; at most, some applications can show 40% performance improvement.
Incidentally, introducing a second physical CPU will not double performance either, due to increased need of locking and other inefficiencies.
For example, when I measured timing for executing (in a tight loop) 'Interlocked.Increment' (or InterlockIncrement, or the assembler LOCK INC instruction) on a single proc (no hyperthreading) vs. a dual proc (no hyperthreading) machine, the results show an order to two orders of magnitude slower on a multi-proc machine (since the two CPUs need to be coordinated). Still, many *cpu-bound* multi-threaded applications would show around 90% improvement when a second CPU is introduced.
Q: Would running my code on a a hyperthreaded machine discover all the concurrency bugs that running it on a true dual-proc machine would?
A: No.
It is true, as my article outlines, that many multithreading bugs that are hard to reproduce on a single-processor machine would show up when running your application on a hyper-threaded machine. But the sequence and timing of code execution is different between true multiproc machines and hyper-threaded machines. To be on the safe side, you need to test your application on both.
Q: A developer in my team asked for a dual proc machine, but I gave him a hyper-threaded machine instead. Why is he unhappy?
A: Hyper-threaded CPUs are not as fast as multiple physical CPUs.
Q: So how *should* I detect hyper-threading from .NET code, especially on Windows XP?
A: The article mentioned the Windows API Call GetLogicalProcessorInformation, which is not supported on XP.
While there is no way to detect HT from C# on XP, which would require assembler call to the CPUID instruction, Intel provides this code sample that (using C++, which does allow inline assembly) detects Hyper-threading. This code would work on both XP and Windows 2000/2003.
Q: Did you hear about a hyper-threading inherent security flaw?
A: I have read the article at http://www.daemonology.net/papers/htt.pdf ; it suggests a 'timing' attack on cryptographic operations executed from a seperate process running on the same machine.
It is not clear whether this attack is practicle under Windows (the only examples were FreeBSD and other Unix variations) but at any rate it should not impact how an application developer would structure their code; If this is an issue, this should be resolved by chip designers and cryptographic library providers.
As more information becomes available, I'll update this page.
More Useful links:
Identifying Hyper-Threading: http://www.intel.com/cd/ids/developer/asmo-na/eng/212489.htm?page=3
Cache Blocking on .NET: Improve performance http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/threading/implementation/170317.htm
cache blocking on hyper-threaded machines: http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/threading/implementation/20461.htm
Hyper-threading tutorial: http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/threading/implementation/20461.htm
Thread priority and hyper-threading: http://www.intel.com/cd/ids/developer/asmo-na/eng/180218.htm?page=2
Develop multi-threaded applications using .NET http://www.intel.com/cd/ids/developer/asmo-na/eng/newsletter/20463.htm?page=4