Log in

No account? Create an account


Previous Entry Share Next Entry
phyrexian @ 12:06 am: A random note about INTEL.

I must admit, I’m an Intel fan boy. That I can’t deny.

Recently the issue of Hyperthreading, and the pro’s and con’s of the technology have been questioned. Here’s my take on this topic.

Hyperthreading, a history:

Hyper-Threading is Intel's trademark for their implementation of the simultaneous multithreading technology on the Pentium 4 microarchitecture. It is basically a more advanced form of Super-threading that first debuted on the Intel Xeon processors and was later added to Pentium 4 processors. The technology improves processor performance under certain workloads by providing useful work for execution units that would otherwise be idle, for example during a cache miss.

The advantages of Hyper-Threading are listed as improved support for multi-threaded code, allowing multiple threads to run simultaneously, improved reaction and response time, and increased number of users a server can support.

Hyper-Threading works by duplicating certain sections of the processor—those that store the architectural state—but not duplicating the main execution resources. This allows a Hyper-Threading equipped processor to pretend to be two "logical" processors to the host operating system, allowing the operating system to schedule two threads or processes simultaneously. Where execution resources in a non-Hyper-Threading capable processor are not used by the current task, and especially when the processor is stalled, a Hyper-Threading equipped processor may use those execution resources to execute the other scheduled task. (Reasons for the processor to stall include a cache miss, a branch misprediction and waiting for results of previous instructions before the current one can be executed.)

Except for its performance implications, this innovation is transparent to operating systems and programs. All that is required to take advantage of Hyper-Threading is symmetric multiprocessing (SMP) support in the operating system, as the logical processors appear as standard separate processors.

However, it is possible to optimize operating system behavior on Hyper-Threading capable systems, such as the Linux techniques discussed in Kernel Traffic (http://www.kerneltraffic.org/kernel-traffic/topics/Hyperthreading.html). For example, consider an SMP system with two physical processors that are both Hyper-Threaded (for a total of four logical processors). If the operating system's process scheduler is unaware of Hyper-Threading, it would treat all four processors the same. As a result, if only two processes are eligible to run, it might choose to schedule those processes on the two logical processors that happen to belong to one of the physical processors. Thus, one CPU would be extremely busy while the other CPU would be completely idle, leading to poor overall performance. This problem can be avoided by improving the scheduler to treat logical processors different from physical processors; in a sense, this is a limited form of the scheduler changes that are required for NUMA systems.

According to Intel, the first implementation only used an additional 5% of the die area over the "normal" processor, yet yielded performance improvements of 15-30%.

The major problems with Hyperthreading, Is not the Hardware, the hardware operates flawlessly, as the concept design allows. The problem is in the software.

One major “Flaw” in the hyperthreading debate, is the prevention of XD “software”. XD, or eXecute Disable bit, prevents certain areas of memory from being executed, preventing Overflow viruses from running. The issue arises, that two computers on a local area network, can still execute code remotely. To prevent this, Micro$oft Windows products, add a prerequisite to the execution of any software on the local machine. The thread requires a username/Password combination, including the user name, and the machines name.

This effectively prevents one operating system from executing code from the other, due to the TCP/IP stacking rules that prevent any two computers from acquiring data from a computer with the same “machine name” as any other.

The issue arises, that ANY Symmetric Multi-Processor machine, does not follow the TCP/IP stacking rules, as they communicate via the Netburst interface. CPU0, can execute any code in memory, unless it’s flagged XD’d. CPU1 abides by the same rules, as that the XD’d bit table is stored in main memory. A Hyperthreaded CPU however was never designed to follow XD bit rules, and never check’s to see whether a memory address has an XD flag.

This is a very simple problem, that M$ can’t seem to fix, if CPU0, the physical processor, flag’s a memory address, why is the compiler passing anything to do with that memory address to CPU1, the logical processor?? It’s the compilers job to schedule tasks, but yet it fails to even check if a memory address has an XD flag.

As I see it, Hyperthreading, is a technology that allows us to get more done. The hardware work’s perfectly, yet the software is flawed. Still, people blame INTEL for their issues. Work on the TCP/IP-V.6 stacking protocol, and enforce MAC registry per packet, you increase the overhead minimally, and gain the ability to track a packet across the net. Casual viruses and spam would all but disappear, and the internet would see some real traffic, not thousands of request’s for new Anti-virus definition files.



Date:November 13th, 2009 12:52 pm (UTC)
Строительные материалы — материалы для возведения зданий и сооружений.
Powered by LiveJournal.com