Re: PSI MIPS (was: Links to decent 'why the mainframe thrives' article)

On 20 Jul 2007 23:35:18 -0700, in bit.listserv.ibm-main you wrote:

----- Original Message -----
From: "Timothy Sipples" <timothy.sipples@xxxxxxxxxxxx>
Newsgroups: bit.listserv.ibm-main
To: <IBM-MAIN@xxxxxxxxxxx>
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.

I suspect that slower or faster may depend on workload. If there is a
lot of decimal arithmetic (native on z, simulated in part or all on
Intel, Power and RISC), the mainframe will be a lot faster for the
arithmetic part. On the other hand, IBM came out with XPLINK and
other tweaks because C/C++ performance was so bad on z series. I
would like to see a test with optimized COBOL and web server on the
various platforms. Also a COBOL and DB2 benchmark across platforms
would be useful. As someone who likes COBOL and z, I am dismayed by
the probable demise of both in part because of what I believe to be
bad management of both products.

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.


Since a large percentage of PCs are sold with non-parity, non-ECC
memory, I doubt that anyone knows the true error rate of Intel
processors. I wonder how many glitches attributed to Windows are
actually hardware problems. It would be instructive to know how many
times a processing error is actually detected by the z hardware.

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

Clark Morris, semi-retired MVS person

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.

Relevant Pages

  • Re: PSI MIPS (was: Links to decent why the mainframe thrives article)
    ... does not equal doubling the clock speed of a single core. ... Either mainframe CPUs are slower, ... more frequent as clock speeds increase, temperatures rise, and densities ...
    (bit.listserv.ibm-main)
  • Re: Article on IBMs z196 Mainframe Architecture
    ... mainframe with an out-of-order CMOS microprocessor, ... So when they started putting more than one of what a mainframe person would call a "processor" on a single chip, that would produce "a processor with two processors", which sounded stupid, so the old word "core" was co-opted to make it "a processor with two cores". ... Wherever possible, if the system can see that it is possible, and there are electronic resources available, an instruction can be executed before the instruction before it has finished. ...
    (comp.lang.asm370)
  • Re: Holy Shit Does Linux SUCK!!!
    ... Not unless you have a mainframe from the 1960s; nobodyuses core ... Unsolicited bulk E-mail subject to legal action. ... right to publicly post or ridicule any abusive E-mail. ...
    (comp.os.linux.misc)
  • Re: Migration from Mainframe to othre platforms - the othe bell?
    ... Once they start multiplying the number of little servers they need to run the ... The mainframe people know how to write fault tolerant applications. ... El contenido del presente mensaje y sus anexos es privado, ... profesional o por disposiciones legales y/o reglamentarias vigentes. ...
    (bit.listserv.ibm-main)
  • Re: 25 reasons why hardware is still hot at IBM
    ... there are fewer fibre HBAs in most servers than there are FICON ... http://www.garlic.com/~lynn/2010h.html#51 25 reasons why hardware is still hot at IBM ... group had been told that they had to use PS2 microchannel adapter cards ... mainframe servers, you can bet that IBM is not exactly enthusiastic ...
    (bit.listserv.ibm-main)