Re: Supposed factor improvements over time in the integer performance of processors, there are some faulty numbers in this discussion, or at least misleading. It has to do with cores versus chips.
Dean, with all due respect, no matter how much you try to fuzz it, they're not directly comparable. The X86 architecture going to two cores and now quad cores was the only way X86 engineers could simulate a Moore's Law improvement. But the dirty little secret is that two cores most definitely does not equal doubling the clock speed of a single core. I think your math is pretending otherwise, but that's not the real world of business computing. Another dirty little secret is that today's typical X86 software is lousy at taking advantage of multi-cores. And yet another dirty little secret is that almost all software vendors charge more for multi-core, so moving to the supposedly higher performance multi-core design might actually raise your cost of computing. (This is a very real problem now. Single core processors are still in demand, especially for light duty test servers, development servers, branch servers, and education/training servers, in order to minimize the cost of the software.) Oh, there's another dirty little secret. Execution errors are becoming more frequent as clock speeds increase, temperatures rise, and densities shrink. Keeping those electronics flowing in the right places is getting tougher, and more often they're leaping out of their little cages resulting in two plus two not equalling four. This is most unacceptable in the financial transaction processing world, for example, which is why IBM mainframes protect against execution errors. It's yet another metric SPECint doesn't seem to report, the long-term processor error rate. If you want to look at integer performance on a benchmark, stick to per core numbers if you're comparing cores. And you'll discover that processor engineers are struggling to increase core speeds, and Moore's Law has probably stalled already. Maybe that's why Intel is cutting back on R&D? :-) This multi-core problem is not new to IBM. The solutions (plural) require a total system design perspective, including software. Re: Token-Ring and Ethernet, yes, really lousy analogy. The progression in networking technology mainly had to do with the emergence of network switching, effectively obsoleting both Ethernet and Token-Ring. It had nothing in particular to do with Ethernet getting faster, because Token-Ring did, too (4, 16, 100 Mbps). Both camps had the "wrong" formula originally, and bits of each survived and converged. The Token-Ring camp was entirely correct that Ethernet collision handling sucked, and so that got bypassed and completely replaced with something at least closer to Token-Ring's idea (i.e. switching) along with full-duplex. Ethernet "won" the logical signalling over the now non-colliding short hop to the switch. And neither camp got the wiring "right" at first, something of great import to actual, real businesspeople like facilities managers. Both camps changed the wiring to something else, though IBM's 1984 wiring foundation was over-engineered and could be recycled. I've been in so many buildings that very successfully installed RJ-45 adapters and kept right on going, to this very day, while traditional Ethernet's wiring usually had to be chucked completely. There's another case like Token-Ring v. Ethernet: the contemporaneous battle between Micro Channel Architecture (MCA) and AT bus (ISA/EISA), both invented by IBM (except the EISA extension), oddly enough. Which one won? Answer: neither. They're both gone. Bits of each got folded into PCI, Cardbus, ExpressCard.... Except maybe MCA did "win" in spirit. PCI has much more in common with MCA. When PCI first came out, people even spotted that, remarking that it was simply a reinterpretation of MCA. And now we come full circle, because guess what's inside even the latest System z9 mainframe? Yes, PCI, albeit far enhanced from the original. You can buy CryptoExpress2 adapters, for example, to go in those slots. - - - - - 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
