----- Original Message ----- From: "Timothy Sipples" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Friday, July 20, 2007 10:43 PM Subject: Re: PSI MIPS (was: Links to decent 'why the mainframe thrives' article)
>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. I didn't do any math. I reported SPECint numbers - for both single core and dual core. The numbers I provided were single processor, single core results up to June 2006. > 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.) Why is this relevant to the discussion, except as a way to again move it away from the question of processor performance. I understand the desire to defend the faith at all costs - but this is just a simple little issue. If processor performance doesn't matter, then why is the fight to defend it so fierce? Either mainframe CPUs are slower, or they are not. Instead of all these 'dirty little secrets', and 'leading technology' arguments that have nothing at all to do with the issue, except to widen the discussion so it can be 'won', we either present the figures and deal with them, or just agree to disagree. >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. This, of course, is a red herring. We've already had Tom Marchant claim that IBM is leading in process technology, and now we are hearing that these improvements are causing increased errors that are unacceptable for mainframes. This is typically called FUD. >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? >:-) More FUD. As I said - I compared single chip, single core performance. >This multi-core problem is not new to IBM. The solutions (plural) require >a total system design perspective, including software. Such as Linux and open source. Yep, only IBM has the answer. The FUD gets more intense. I think John Gilmore is right - this thread has probably run its course. I'm a staunch mainframe advocate, but I think it's OK to give credit where it is due. I haven't seen anything to rebut the notion that mainframe processors are slower than other architectures, and it doesn't seem like we are going to get there from here. >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). Actually, according to the presenters it had *everything* to do with it. The point was that Ethernet was *cheap* and ubiquitous. Engineers could ratchet up the speed of the Ethernet network to overcome the inefficiency cheaper than they could ratchet up Token Ring speeds, and customers didn't care about efficiency. The reason I brought it up was because of the efficiency argument - which is, again, not the real issue. The real issue is the economics, and that was the point of the analogy. >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. I believe that the lesson there is that the economics determines the 'winner' in the market. Commodity components are finding their way into mainframes, because that is necessary in order to compete. Those commodity components, because of the amount of money invested into the technology, end up faster than the specialty components they replace. Not because they are better designed, but because the competition in the market they are used in is intense. The point being that it isn't unusual for a 'cheap' commodity part to end up replacing the highly efficient, well engineered specialty part because it turns out to be both cheaper *and* faster. And this is what my original argument boils down to - it has been suggested to me by people who are involved with these things that the volume parts, in particular x86, has and will inexorably overtake everything else in performance. At the moment POWER is the exception, from what I understand - and Intel keeps throwing money at Itanium to keep it competitive, but who knows how long that will last. Anyway, thanks to all who provided links and data. That made the thread useful to me, at least, even if it annoyed many others. Regards, Dean ---------------------------------------------------------------------- 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
