Smart stuff, this. With the new hyperthreading architecture that graces its latest server processors, Intel has effectively replicated many of the internal components of the Pentium 4 micro architecture, creating a virtual image of a second processor running within the same silicon.
Through a clever manipulation of the CPU’s internal “architecture state” (the contents of various control registers and external interfaces), a hyperthreading CPU can execute two unrelated code paths in parallel, with instructions from each path vying for resources in a shared execution core.
Of course, there isn’t really a second CPU; it just looks that way to the operating system. In fact, the illusion is so complete that when you first power up a hyperthreading-enabled system, the BIOS POST (Power-On Self Test) reports the total number of virtual (as opposed to physical) processors. And as goes the BIOS, so does the operating system. Case in point: Microsoft Windows. When booting to Windows 2000 or XP on our state-of-the-art Supermicro P4DC6 dual-Xeon DP test bed, we found that the OS was completely fooled by the virtualisation scheme. Windows Device Manager dutifully reported the presence of four 2GHz Xeon CPUs, despite the fact that the system sported just two physical processors.
Two heads are better . . .
Fooling the OS is one thing. Wringing more performance out of an otherwise unmodified processor core is a little more difficult. Intel claim that customers can expect a boost of 10 per cent to 30 per cent, depending on the application type, thanks to the more efficient use of core resources by the dual virtual CPUs, that are treated as separate processing units by symmetrical multiprocessing (SMP)-aware operating systems such as Windows 2000 and XP.
Our own testing shows that Intel’s projections are in fact quite conservative. For example, when serving SQL transaction data to a series of Windows 2000-based clients, our hyperthreading-enabled Xeon DP test bed delivered round-trip throughput an average of 46 per cent faster than the same system with hyperthreading disabled (a simple BIOS switch controls the feature). Likewise, when we ran a similar scenario using a Web-based, three-tier application simulation we saw a boost of more than 31 per cent when we enabled hyperthreading.
To put these numbers in perspective, you’d need to increase the core frequency of the CPUs by greater than 1GHz to match these results using non-hyperthreading processors. We know this because the very same scenario executed against a similarly equipped (in terms of peripheral components) dual 1GHz Pentium III server delivered results that were 34 per cent slower than our 2GHz Xeon test bed with hyperthreading disabled.
If an extra 1GHz yields a 34 per cent improvement in database server throughput with traditional (non-hyperthreading) CPUs, it seems clear that, as an on-chip throughput enhancement, hyperthreading is delivering performance on a scale that transcends mere clock frequency.
Hyperthreading represents a potent combination of parallelism and pipeline efficiency that will give Intel a huge leg-up on the competition as it expands the technology to encompass the range of Pentium 4 derivatives.
Brass tacks and road-worn rubber
Ironically, it is on the issue of where and how they plan to introduce hyperthreading that Intel is being the most reticent. Outside of the newly-introduced Xeon DP and MP chips (the former is the one we tested; the latter includes a large Level 3 cache to support four-way and higher SMP platforms), there are no publicly announced plans to incorporate the technology in any other products. Intel’s official position is that hyperthreading is a server-only technology, and the company is asking Xeon OEMs not to allow hyperthreading to be turned on in desktop and workstation BIOS code.
Although Intel is discouraging speculation about hyperthreading’s role in future desktop or workstation solutions, clearly this is a technology that is destined to permeate the very fabric of Intel’s universe. As for why Intel is focusing exclusively on servers with this initial release, we can only speculate that it is trying to manage customer expectations.
After all, not every application will benefit from parallelism at the CPU level, and the last thing Intel wants to do is to hype a concept that might confuse the non-technical masses. Add to this the ubiquitous “compiler updates” from the various tools vendors (to fully optimise application code for parallelism and so on) and you can see why Intel is taking it slow.
Finally, no story this compelling would be complete without a bit of controversy. In the case of Intel’s new Xeon CPUs it has to do with defining what is and what is not a processor. As we noted earlier, hyperthreading fools the operating system into thinking that there are twice as many processors as there are physical CPUs. In fact, Intel is counting on this behaviour because it needs the OS to schedule tasks in a way that can exploit the parallelism that hyperthreading provides.
The problem is that many server products are licensed based on the number of processors in the system. So if you’re a software vendor such as Microsoft, and you offer per-CPU licensing as an option for your flagship SQL Server product, how do you price your product when the customer plans to deploy it onto a hyperthreading server? Conversely, if you’re a Microsoft customer, and you deploy the software onto a hyperthreading server with two physical processors, how many CPU licences do you need to buy? And will the software even run properly if the number of licences no longer matches the number of processors reported by the OS?
These are just some of the thorny issues that Intel will have to sift through as it attempts to translate technical capability into practical reality. A strong market demand (you can never have too much CPU power) should force the software vendor community to get its licensing house in order. Until then, our advice is to proceed with caution. The performance advantages are undeniable and, depending on how the pricing models catch up with the technology, there may be no excuse for investing in anything but hyperthreading-capable servers.
In an effort to test the real-world scalability of Intel’s new hyperthreading Xeon CPUs, we built a custom server solution around a Supermicro P4DC6 motherboard. We chose Supermicro because it was strongly recommended by Intel and also because it was one of the only vendors with a shipping solution that supported hyperthreading.
To the Supermicro board and case we added a 15,000RPM, Ultra160 SCSI hard disk, an Intel Pro 1000XT Gigabit Ethernet Server NIC, and 512MB of PC800 Rambus DRAM. The operating system was Windows 2000 Advanced Server with Service Pack 2 and featured SQL Server 2000 (also Service Pack 2 level). The test clients consisted of a mix of Pentium III and Pentium 4 PCs running Windows 2000 and equipped with Intel Pro 1000 Gigabit Desktop NICs. The entire solution was connected via an Intel NetStructure 480T Gigabit Ethernet-over-copper switch.
Our first test scenario consisted of five physical clients conducting OLE DB-based SQL transactions against both hyperthreading-enabled and hyperthreading-disabled server configurations. To simulate multiple, concurrent SQL clients we employed the ADO Stress module from Benchmark Studio Professional Edition 2.0 (www.csaresearch.com), scaling the number of instances per client from 2 to 10 for a total of 50 concurrent, active client/server connections.
For our second test scenario we used Benchmark Studio’s ASP Stress module to simulate an Active Server Pages (ASP) Web client interacting with a three-tier, database-driven Web site. Once again, we scaled the number of concurrent instances per client from 5 to 20 for a total of 100 active ASP sessions conducting OLE DB transactions against SQL Server.