Dean Kent writes: >[Re: SOI technology.] >It has not been shown that either of these provides any benefit in >performance, and has nothing at all to do with feature size. It was >supposed to help with leakage, but Intel seems to be doing quite will >without these.
We're getting way, way far afield here, but there are a few points to tidy up. Indeed Intel has not widely deployed SOI, though their primary objection is "cost" and not "value." (Patent royalties?) And Intel does concede they see value in an SOI variant called FD-SOI. Also, Wikipedia happens to disagree with you re: the usefulness of SOI. I realize Intel has its point of view, but Intel <> the semiconductor market. Re: Copper, IBM invented it and now virtually all semiconductor companies, including Intel, use it. >However, IBM is positioning the mainframe to compete >in some of the same markets that x86 competes. "Some," yes. IBM also sells lots of X86 servers (and software and services): http://www.ibm.com/systems/x An IBM rep would be happy to work with you to understand which server(s) is(are) appropriate for your particular business. And it'll have extremely little to do with SPECint. :-) >As far as the largest semiconductor manufacturers in the world, >Intel is #1, with Samsung, TI, Toshiba and STmicro rounding out the >top 5. IBM isn't listed in the top 10 list. AMD was listed as >#7 as of Dec 2006, so the two leading x86 manufacturers are in the >top 10. This, of course, has absolutely nothing to do with whether >any given product is a better performer than any other. Big problems with that ranking you've got, though. For one thing it excludes foundries -- you know, the places where chips are actually made. :-) IBM is a substantial foundry for other companies on the list. Also, that list excludes royalties and R&D services, areas where IBM happens to make lots of money -- and which are the most relevant for purposes of this discussion thread. >It was stated that IBM invests $1.2B annually on mainframe R&D >(hardware, software and services). Intel, on the other hand, >spends almost $6B on their semiconductor business alone. Please do note that that advertised figure is *direct* investment. If IBM invents SOI or, more recently, airgap nano-assembly, that R&D money is not counted in the "z bucket" even though it has a huge beneficial impact. And, no, Intel does not spend nearly $6B on its "semiconductor business alone." That figure is the company's *total* corporate-wide R&D budget -- and Intel expects that figure will dip to roughly $5.3B in 2007, by the way. Maybe the X86 market isn't so competitive this year. :-) I'm sure it's mostly semiconductors, since that's Intel's core business, but some portion is not (e.g. compilers). It also includes such things as wireless chip, graphics chip, and flash memory R&D, areas largely irrelevant to business server development. R&D related to notebook computers, PDAs, mobile phones, and other small devices has only partial relevance to business servers, and mobile computing is really Intel's focus at the moment. Now, that's still a lot of R&D money, but for comparison IBM's annual corporate R&D budget exceeds $6B. Re: Fault tolerance, software plays no role? Of course it does. Could you lash together two X86 or Itanium chips and have them execute in parallel? Yes, you could. But the software above it is the huge problem. The IBM mainframe design is unique in pushing RAS down deeper into the hardware and in having the most mature, popular, business-oriented operating system and middleware products riding shotgun. Granted, I worry about software a lot, but it really is extremely important. The goal is to achieve a business result (continuous business service, including planned events), remember. I notice nobody ever mentioned multi-level cache memory structures in massively SMP systems. You know, something IBM mainframes have. It's a very difficult piece of engineering. It also happens to be the most useful system attribute for consolidation and virtualization. And that's a huge problem with the benchmarks you've listed. SPECjbb is fine if you're running a single Java 3-tier application. What if you're running 50 of them, in 3 different programming languages, with 100 batch jobs? With varying service classes? How do you benchmark that, which is exactly the real world use of these special systems -- "data center in a box"? Tough problem. Never mind computing resources for DR, training, education, testing, development, etc. By the way, the reason that total MIPS shipment figures are relevant, at least to some extent, is that mainframe MIPS are actually *used* and, as close as anything in the world of computing, that translates into increased business activity with the systems. Nobody with a budget ever buys extra MIPS "just because": there's no purpose and no advantage. In contrast, the vast bulk of X86 MHz/GHz shipments (99+% I'd guess) simply wait faster, because the vast majority of those chips get installed in desktop PCs and notebooks only to loop-idle while the user decides where to move the mouse or which key to press next. As I'm doing (er, not doing) right now as I type this e-mail while the X86 chip under the hood mostly waits for my slow human interaction. And when the CPUs do run through some instructions, very often they're delightfully pretty screen savers to entertain and amuse the one person every month who might glance at the screen. You see, the problem is that if anybody actually took a close look at the total installed base of X86 MIPS they'd be utterly shocked at how much waste there is, especially in energy, which is probably why the vendors don't want to talk much about that. SpeedStep and sleep modes are two methods for slowing these chips down when they aren't doing any productive work (which is most of the time), but much more can be done. All that said, I don't know why you're trying to make this complicated. The way you evaluate which server(s) you need is actually quite simple, at least from a theoretical point of view: 1. Determine your functional requirements (processing insurance claims, providing cash to ATM customers, etc.) Look at full business-wide scope as much as you can. 2. Determine the associated non-functional requirements (security, scalability, availability, execution integrity, disaster recovery, etc.) Establish hard numbers (RTO, RPO, etc.) as much as you can. 3. Go shopping. I would argue that System z is the easiest system for businesspeople to understand conceptually. Everything about the system is built for direct business relevance, e.g. WLM goal mode. Relating distributed servers to business function (and qualities of service) is much, much more complicated. Witness the fact so much discussion bandwidth has been spent on MHz and GHz, when I guarantee the CEO couldn't give a damn. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
