Dr. Dobb's Journal August, 2004
It has become clear enough: The Pentium 4 architecture has just about reached its limits. There will be some marginally faster Prescott and possibly even Northwood chips coming, but they won't go very far. Peter Glaskowsky notes that Intel has been stuck near 3 GHz since the end of 2002. "We're one full Moore's Law generation past the 3.06 GHz part's introduction, and the Pentium 4 is only 10 percent faster." Intel has achieved good yields on 3.2-GHz chips, but not on 3.4, and the faster they shoot for, the worse the yield.
Now Intel always has the option to make a lot of Pentium 4s and cherry pick the very fastest, but it's an expensive way to stay in the game against AMD; and AMD 64-bit systems with nVIDIA support just keep getting better and better.
The bottom line is that Intel decided to bite the bullet. Tejas, the successor to Prescott, is gone. It seems clear to me Prescott won't be ramped up much, and the Pentium 4 architecture is essentially as good as it is going to get. We are at the end of an era.
Understand, what we have is pretty good. I'm running both Prescott and Northwood 3.2-GHz Intel systems, and they are not only faster than any software I want to run with them, they're faster than any software I know about (except for games). The people who think of the best Northwood and the early Prescott systems as "limiting" are generally the people who build extreme game machines.
But gamers don't want Northwood or Prescott anyway: They want Athlon systems. One reason came out at WinHEC: 32-bit applications run faster on 64-bit systems. All this is great for AMD sales—and I can say that my next extreme game system will be AMD based.
With the cancellation of Tejas, for the first time Intel has nothing with which to compete with AMD at the high end, and that situation will continue through this year and perhaps beyond. It's unclear when the first of the new dual-core replacements for Pentium 4 will come out, but that's probably not much before mid 2005. Naturally Intel will hurry as fast as it can. I don't expect dual-core server parts before 2006, leaving Intel with nothing to pitch against AMD's Opteron.
The new processors will introduce a new technology to desktop systems. There will be two cores to each chip; in essence, each CPU will be a dual-processor system, with the processors close enough together to take full advantage of the duality. Intel believes this approach will deliver extreme performance while keeping heat dissipation under control, and early experiments have been very encouraging. Pentium M systems are said to be almost as fast as current Northwood and Prescott, but with less heat generation. Intel never comments on unreleased parts, so this is all speculation, but we can wish them well at these efforts.
Pentium M architecture is derived from the Intel Mobile Pentium chips. Those are single core, but the new desktop chips incorporate two cores in each chip. Note that software sees single-core systems with Hyperthreading Technology as systems with dual processors, and therefore the Pentium M dual-core systems will run that software without problems. The latest Intel move doesn't abandon the considerable effort put into writing applications to run faster with Hyperthreading Technology, and this is where Intel hopes to stay competitive in the very high-end gaming systems world. Dual-core Pentium M systems should rock. But we won't have them for a year or more.
Meanwhile, AMD keeps rolling along, bringing out better and better 64-bit systems while their partners at nVIDIA improve both the graphics and the support and glue chips to make AMD motherboards. Almost as an afterthought, as WinHEC 2004 closed, AMD also announced 64-bit mobile CPUs.
Everywhere we looked at WinHEC we saw 64-bits. It didn't have to be this way, but today's 32-bit software runs somewhat faster on today's 64-bit systems, and that's without any special effort to make it happen. Part of this is due to increased efficiency in the operating system overhead, of course; but the bottom line is that if you're in need of more speed, 64-bits looks to be the way to go.
Buried deep in some of the WinHEC presentations was a surprise: Microsoft Windows 64-bit Windows XP won't run 16-bit software. Moreover, it's not at all clear that Longhorn will do it either. Brian Marr in a business strategy session flat out said that 16-bit Windows is going away, while Samer Arafeh, another software design engineer for the Windows base OS kernel, had a slide proclaiming "No 16-bit support on 64-bit Windows. Win32 API's for 16-bit support are stubbed out to fail."
This is a huge change for Microsoft. Only a few months ago at the Microsoft Professional Developers Conference (PDC 2003), Bill Gates himself said that "All old applications will continue to run" in 64-bit Windows. The tricky part is that the change is in the WinHEC briefing slides, but it wasn't emphasized, and was never mentioned in the keynotes at all.
Note that in practice Microsoft won't entirely abandon 16-bit legacy applications, but the support will be much the same as the legacy support for older DOS software in Windows XP: virtual servers, and virtual machines to run the older applications. Having just struggled to get Railroad Tycoon, an older DOS game, running on a Windows XP machine I know more about Virtual DOS and DOSBOX than I really wanted to; but in fact they do work, and you can get the older DOS stuff running if you really want to, and I don't expect it to be more difficult for those who need 16-bit applications to run on a 64-bit system. Once set up, users should neither know nor care that their 16-bit applications are running in an emulator; they should still Just Work.
The intriguing question, and one not answered at WinHEC, is whether Longhorn (the next generation Windows) will have direct provisions for 16-bit applications? It's not clear to me that there will be a 32-bit version of Longhorn at all. I have seen neither confirmation nor denial. I do know Microsoft would prefer not to release any more versions of Longhorn than needed, and if there were no 32-bit version of Longhorn it would simplify matters considerably.
On the other hand, new 32-bit computers are very fast and there will be a lot of 32-bit machines in use when Longhorn comes out; and Microsoft seldom, if ever, abandons a large potential market. If I had to guess, I would say there will be both 32- and 64-bit versions of Longhorn, with a decided shift of resources over to the 64-bit side.
First, some terms: "Aero" is the user interface (UI) for Windows Longhorn, and is built atop "Avalon," Longhorn's presentation layer. Avalon, "WinFS" (the still-upcoming Windows future file system) and "Indigo" (the communications layer, for talking to everything from Web to COM ports), make up "WinFX," the "programming model for Longhorn."
While it's still very much under development, Aero is now far more precisely defined than at WinHEC 2003, or even at November 2003's Microsoft Professional Developer's Conference (PDC). The developers have struggled mightily to sketch in the missing details of what Longhorn will look like, how developers will interface to it, and the associated hardware requirements. This isn't being done in a vacuum: At both this WinHEC and last year's, every graphics presenter asked for feedback on what developers would like to see, justified the decisions made so far, and went out of his or her way to answer questions. This is important, because Longhorn will be the "biggest architectural advancement since Windows 95, at least for graphics, text, and media," as Greg Schechter, Microsoft's software architect for the Windows Client Platform said in his Avalon Graphics Stack overview.
Among the biggest changes: GDI/GDI+, the Graphics Display Interface and current main method for drawing windows on the screen, is going to become a second-class citizen. While all existing GDI calls will continue to work for existing applications, the entire OS (and presumably future apps) will use Avalon for rendering. The minimum graphics card requirements for Longhorn will be a DirectX 9 card with Shading Model 2. We will follow this up next month.
Another: The GPU, the Graphics Processing Unit, will be used to accelerate the rendering in Windows. In the past, almost no Windows display calls were accelerated using the graphics chip; all that was done in CPU and main memory. Currently, when an application moves over another, Windows tells each one to redraw. That's reasonably fast on modern machines, but is inelegant at best. Redraw-on-command causes the "screen droppings" problem, where moving one window over another writes copies of the upper window on the lower one. XP and earlier versions of Windows use little of the available video memory; when you scroll a Word document, the scrolled text loads from main memory into video memory one chunk at a time.
Longhorn will use video memory to cache scrolling HASH(0x80d2d8), and generally make better use of it. Think of how much faster PowerPoint could scroll through a long presentation if the next slide was rendered into video memory before you got there. As an example, David Brown, the development lead for the Windows Text Team, demonstrated preview-scrolling through a long formatted document; as he did, a ghostly copy of the page you were passing by appeared next to the scroll box. He confirmed that this really cool feature was essentially "free," easily accessed by applications using the WinFX APIs. Better, it was a live preview, updating as the application did; if there was an animation in the page you scrolled by, a tiny live animation would play on the preview. If this feature works as well as his demonstration, it will be an excellent navigation tool.
David Brown is at heart a typography nerd, and I use that term as a compliment. At the last two WinHECs, he's covered how Longhorn will handle text display in exotic character sets, such as Thai and Traditional Chinese. At PDC 2003 his team showed examples of properly rendered drop caps, and of a lead capital "L" whose base extended under the next two letters—both situations required hand-coded text rendering in previous Windows. At WinHEC 2004 he talked about how Longhorn will use high-quality text just about everywhere, using subpixel rendering and some other smart tricks. Longhorn will properly display high-quality antialiased text over video right in the operating system, which wasn't possible in the past.
This is going to put demands on the GPU like never before. Because the GPU is going to be tied so tightly to rendering, the Longhorn Display Driver Model (LDDM) will require (among other things) access to soft and hard reset of the GPU, so if the video card gets into an unusual state, Longhorn can klonk it on the head. That's hardly the only change; the LDDM is radically different from the Windows XP driver model, which in turn is quite different from past ones. From the inquiries and comments of the display-driver mavens in the audience, the industry is still trying to absorb all of this. True, ATI and nVIDIA have had staff working in Redmond for several years, but video driver writers (admittedly a relatively small community) are going to have some studying to do.
Other changes: Screen captures have long been difficult to implement, requiring the screen-capture software to fake out Windows. Longhorn will have a simpler interface for grabbing what's on screen. Yet another: Make available all the features of the host PC no matter how accessed. This may be directly, through a linked TabletPC (a method that appeared so often, I suspect that Microsoft is very fond of it), and the main method, remote terminal sessions.
Another big change: LDDM will only allow a single display driver at a time. You can still have multiple display adapters, but they'll have to share a single driver—effectively meaning they'll have to be from the same manufacturer. That seems a reasonable restriction.
Last year, Jim Allchin announced some early Longhorn features and code bits for testing. There was more of that this year, but how much of Longhorn is running in test models and how much is promises and slideware isn't clear.
For example, Windows Future Storage (WinFS Storage) was discussed, but I didn't see any demonstrations of it. You can find out about as much as has been released on the Microsoft site (http://msdn.microsoft .com/Longhorn/understanding/pillars/ WinFS/) but, aside from the fact that the file storage format will include a full relational database, not much else is known.
Clearly, it's time for a new file storage system. Obviously, the original DOS File Allocation Tables (FAT) never contemplated thousands of files some a gigabyte and larger. NTFS did, but finding things in all that clutter is nearly impossible.
WinFS Storage tries to deal with that: Allchin wanted us to be impressed by its relational filing-system capabilities. With WinFS Storage you can, in theory at least, find all files related to each other no matter what their format or where they are stored. This reminds me of Traveling Software's ill-fated Papillion relational filing system, which was a great idea but before its time: The hardware just wasn't up to the job and, of course, it had to layer over FAT; this time, the relational elements are to be built into the File System itself.
We were given a demonstration of some of its capabilities: a lawyer building a case file. It was really impressive, but it was a demo and I have no idea how much was hard-coded concept illustration and how much was actual working code. If WinFS works the way Allchin seems to think it will, I can hardly wait. I find I wrote the word "INCREDIBLE" four times on my Tablet.
Long time readers may recall "Cairo," an earlier Microsoft attempt at building a relational filesystem. That never shipped, probably due to hardware limits as much as anything else. Microsoft seems to have higher hopes for WinFS; but in any case, WinFS must work perfectly, first time, every time, or it will be a huge liability. Microsoft can ship Longhorn without it, and if they have to, probably will. While they were careful never to mention an actual date, the unspoken promise was about WinHEC 2006; in any case, about two years from now. That will have been five years since Windows XP. On to Cairo!
The game of the month remains Star Wars Galaxies (SWG), the online massively multiplayer roleplaying game based on the movie series. I suppose at some point I'll go back to Dark Age of Camelot, or even Everquest. I've never given up my accounts. But I have managed to get Ventrilo (http://www.ventrilo.com/) working on SWG and that adds a lot. Ventrilo is a voice communication system that works shamelessly with SWG, and has a lot of nifty features like button mapping. I've mapped the center wheel button (never used in SWG) to be the push-to-talk switch. I'm using it with a Plantronics behind-the-head headset, and it all Just Works. It's a lot of fun to hunt huge beasts with a team of comrades you can talk to.
The computer book of the month is Chris Hurley et. al., WarDriving: Drive, Detect, Defend, A Guide to Wireless Security, (Syngress, 2004; ISBN 1931836035). The title says about all you need to know. If you want to try some WarDriving, you need this book. And if you're concerned about being a victim, you certainly need it.
DDJ