Hyper-threading: Intel's call to action
I used to follow the processor business very closely and go to Microprocessor Forum, the premiere show in the industry, every year.
One of the arguments made by the hardware geniuses, although never very loudly, was that software people weren't doing enough to keep performance improving. Instead they were relying on CPU techniques like superscalar design and superpipelining and ever-bigger caches. If only programmers would start using more high-level parallelism in their programs, the argument goes, we could use more than one CPU at a time and systems would really start to boogie.
Intel has finally dared the software world with their new hyper-threading chips, first to make an appearance in new Xeon chips available by the end of the month. It's a smarter approach to an old idea from the same hardware geniuses I mentioned above: SMP-on-a-chip. A real dual-processor system is considerably more expensive, not least because it has two actual CPUs in it. The classic SMP-on-a-chip idea is to put two CPU cores on a single chip, but this still makes for an outrageously large and expensive chip. Hyper-threading works by keeping two (or more) processor states on the chip and having them share access to the functional units, such as the arithmetic logic unit. This makes the chip look like two processors to software, but at a much smaller cost in terms of precious chip real-estate.
To their credit, Intel has been very clear that hyper-threading does not a real dual-processor system make. After all, there's still one cache for them to share and one interface to the rest of the system. But programs that make actual use of that high-level parallelism I mentioned can run a lot faster on a hyper-threaded chip than on conventional designs. See Intel Technology Journal for a lot more on hyper-threading.
So the big question is whether the software business will take up the dare. On the server side I would argue that we're already there. Multiprocessor servers have become cheap and ubiquitous in recent years and Windows NT and Windows 2000 have supported them for a long time. More importantly, Windows has had APIs to facilitate the development of multithreaded server applications that keep them running optimally. I/O completion ports, for example, allow a server application to share a pool of threads with access to asynchronous I/O in a way that keeps the processors busy but minimizes context switching. Use of facilities like this is already well-established, at least among the better Windows server applications such as Microsoft's own IIS and SQL Server. The addition of Hyper-threading should improve performance of such applications considerably.
But not on your current operating systems. Microsoft announced in a recent paper on the subject that Windows .Net Server would support hyper-threading, but Windows 2000 and Windows NT are not written to take advantage of it. On the upside, you'll be relieved to read that Microsoft will not charge you for an extra CPU on your per-CPU licenses when you run their software on a hyper-threaded processor. How magnanimous.
On the desktop side, an inherently multitasking desktop operating system like Windows XP, which has scores of threads running even in a quiescent system, should experience an automatic performance boost from hyper-threading (Microsoft's Jim Allchin said that Windows XP takes advantage of Hyper-threading in a recent in-house interview). But the real payoff should come from multithreaded applications. Some applications do use multiple threads to good effect. The most conspicuous example is background printing in Microsoft Word. Or imagine--hypothetically--an image editing program that could render multiple images or multiple parts of a single image simultaneously.
Still, the desktop is a far tougher nut to crack, and several important factors argue against the widespread use:
- It will be many, many years before a large percentage of desktop systems use hyper-threaded processors; in the meantime, few desktops are multiprocessor.
- Most of the performance benefits of multithreading to desktop applications, on any type of processor, are in terms of responsiveness to the user, and are therefore difficult to measure accurately in a benchmark that can be run automatically and accurately.
- Multithreaded applications are often harder to write, and they introduce several new classes of bugs, generally having to do with different threads contending for access to common resources, that can make programs less reliable. For many developers, the benefits of multithreading may not win out over the new problems they create.
Are you using or considering using new hyper-threaded Xeons for your datacenter? Share your thoughts in our Talkback forum, or send an e-mail to Larry.