× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: AS/400 on Intel?? - Very Long!
  • From: mcrump@xxxxxxxxxxxxxx
  • Date: Wed, 6 Oct 1999 07:44:34 -0500



Interesting thought, but I would seem to agree it is
a step backwards and based on the following excerpt
from Monday Morning Update (Midrange-Computing,
Tim Morgan, Editor) there seems like there would
be little to gain....Also if you read this article there
seems to be some definite opposing views on the
performance claim by Intel.

OS/400 Will Not Be Ported to IA-64
=======================================



With most of us sitting on the edge of our seats waiting
for Intel's 64-bit IA-64 "Merced" chip to hit the market in
mid-2000, midrange analysts and customers are all looking
around wondering how so many different competing processors
and computer architectures are going to make it through yet
another shakeout in the business. The shakeout is
definitely coming (in fact, it's already long since started),
 but the AS/400 is in about as good a position as any other
server--maybe even better once you look at the numbers and
the competitive landscape. And that is why the AS/400
division has no intention of dropping its commitment to the
PowerPC and Power architectures for the foreseeable future.
Here's the problem. Each successive generation of processor
development costs approximately $1 billion to bring to
market. That $1 billion pays for developing new
manufacturing technologies, like CMOS-7S copper and CMOS-8S
silicon-on-insulator, and figuring out how to implement it
in chip production factories. As processor circuits have
gotten smaller and smaller, that cost has risen
dramatically, so by the time we're in the 2001 to 2002 range,
the cost is probably more like $2 billion a processor
generation. These high development costs are what convinced
IBM that, essentially, it had to merge the AS/400 and RS/
6000 server lines, a process that has been underway since
late 1997 when the RS/6000 chip designers in Austin, Texas,
had their cookies saved from burning by the Rochester Labs.

As it turns out, the Rochester Labs were years ahead of the
RS/6000 team in getting a 64-bit PowerPC processor capable
of supporting big server workloads on scalable symmetric
multiprocessing (SMP) servers out the door. That's why the
Apache, Northstar, and now Pulsar RS/6000 servers are all
based on AS/400 designs. (Next year's AS/400 I-Stars are
just 560-MHz versions of the current 450-MHz Pulsar
processors used in the new RS/6000 "Condor" S80 servers.
These I-Star chips will be used in both the AS/400e and RS/
6000 lines.) The Power4 chip is an amalgam of the current
Power3 and PowerPC Pulsar chips, and it will be aimed at
supporting commercial and technical workloads. So by the
time Merced is in full swing, IBM will have a single Power4
processor and a much simpler road map.
IBM will also have three product lines supporting the
Power4 servers, since it is highly likely that the 64-bit
Power4 servers will run the 64-bit implementation of IBM's
OS/390 mainframe operating system. Oh, to be sure, IBM will
probably package the Power4 chips in a multichip module
similar to the current G6 and future G7 processors and
distinct from the processor book packaging used in the AS/
400 and RS/6000 servers, but it is highly unlikely that the
G8 processors will be much different from the Power4
midrange servers. IBM cannot afford the differentiation any
more.
The point is that IBM will have a processor revenue stream
of about $10 billion a year to support its Power4
development efforts, which is by far the largest server
base in the world. Sun Microsystems, which is going it alone
with its UltraSPARC-III development, has a server business
that is about half that size. (It does have a version of
its Solaris operating system for IA-32 chips and is racing
to get a version on IA-64 chips, just in case the floor
drops out of the server market.) Hewlett-Packard's server
base is somewhat smaller, which is why it joined forces
with Intel as a development partner for the Merced chip.
Because Merced will be a year late and plenty of MIPS short
when it ships next year, HP has had to extend its PA-RISC
processor line out a few more years than it would like to.
(Merced has increased HP's chip development costs, not
decreased it.)
The IA-64 chips that come after Merced and its follow-on,
McKinley, will not be high-volume processors (and therefore
low-cost devices) until 2003 or 2004. To further complicate
matters, because the IA-64s use a radically different
computing model called explicit parallelism and thus
require new compilers, the performance penalties associated
with IA-64 chips compared to IA-32s of equal clock speeds
will probably be substantial. I would not be surprised if a
600-MHz 32-bit Pentium III Xeon chip could do more work
under NT or UNIX than an 800-MHz 64-bit Merced chip in a
similar environment.
To get the performance boost inherent in the higher clock
speeds and wider memory paths, software houses and
customers are going to have to recompile their applications--
and they hate that. HP's UNIX customers will be the
exception to this rule, but they will not do much better in
the long run. Apparently, the Merced chip will convert, on
the fly, the PA-RISC instructions used by customers' HP-UX
applications to IA-64 instructions and save these converted
instructions in cache memory, where they can be accessed as
they are needed. It seems likely that there will be
substantial performance penalties to this approach.
When IBM moved from CISC to RISC processors in the AS/400
line, it took a much smarter approach. Without ever telling
AS/400 customers it was doing this, the compilers IBM
created for the AS/400 compiled applications to an
intermediate level that is divorced from underlying
hardware instructions, much as a Java compiler does today.
When these applications are first loaded on a machine, they
are transparently compiled to the specific hardware on the
processor that they will run on, be it a B or F series
processor in the CISC line or a new RISC PowerPC processor.
IBM, being smart, transparently changed the application
binary code to match the new hardware; HP is putting a fake
emulation layer in so unchanged applications can run on new
hardware. This seems to make things easier for customers,
but what happens when you have to reboot the HP 9000 UNIX
server? You have to interactively recreate all those
emulated HP-RISC instructions or store them in files on
disks. If this approach allowed HP to have chips that
increased greatly in power compared to the HP-RISC chips
and cost a lot less money, the added complexity might be
worth it.
But back to IA-64 versus Power4 chip costs. Switching to IA-
64 from Power doesn't seem to make any sense because it
would not save IBM all that much money. But that is not the
only reason to stay by Power4 and Power5. According to
IBM's AS/400 engineers, one of the main advantages to owning
both the hardware and software platform for the AS/400 is
that it allows IBM to create an extremely reliable computer.
 The AS/400 division knows the ins and outs of the 64-bit
PowerPC architecture and its follow-on, the Power4, because
the AS/400 division created it. Moreover, the C++ and Java
programs that comprise the licensed internal code that OS/
400 rides on top of has been tuned like crazy to take
advantages of PowerPC features, and it will be similarly
tuned for Power4 and Power5. Finally, IBM seems-finally--
poised to take the lead over HP, Sun, and Compaq in
processor clock speeds, uniprocessor power, and server
scalability in the I-Star generation and will extend that
lead in the Power4 and Power5 generations. The Power4s will
unequivocally put the Merceds to shame. This will be,
pardon the pun, IBM's time in the sun, and it would be the
height of folly to pull back now. It will also be folly to
charge so damned much for the servers that use I-Star,
Power4 and Power5 processors. IBM, it isn't too late to get
even smarter.
Despite all the reasons for staying with the Power road map,
 the AS/400 division has been practical and done some
contingency planning just in case. For political reasons
(meaning Louis Gerstner throws a hissy fit about costs
because he needs a few extra billion dollars to buy back
IBM stock to prop up net earnings), IBM may have to move
from the Power architecture to IA-64. The good people in
Rochester say that it would take hundreds of programmers
about 24 months to port OS/400's C++ internal code and its
Java extensions to IA-64. My guess is that it would take
closer to 500 programmers to do the job and that it would
cost well over $150 million, including overhead, to do it,
not because of IBM's poor programming skills but because of
the weirdness of IA-64 chip contrasted against the
familiarity of the PowerPC and Power4 chips. OS/400 is
apparently written a lot closer to the PowerPC iron than is
IBM's AIX UNIX variant. IBM already has Monterey/64 (which
is based predominantly on the just-released AIX 4.3.3)
running on Merced prototypes after about a year of
programming. To be fair, AIX had already been ported to the
X86 and mainframe architectures by IBM years ago. AIX also
does not include an integrated relational database
management system like OS/400 does. So the comparison
between AS/400 and AIX porting times to IA-64 is not
exactly fair.




Richard Rosenbluth <rose400@pacbell.net> on 10/05/99 04:14:39 PM

Please respond to MIDRANGE-L@midrange.com

To:   MIDRANGE-L@midrange.com
cc:    (bcc: Mike Crump/IS/Ball-Foster)

Subject:  AS/400 on Intel??



>
>         InformationWeek Daily 10/5/99
>         Tue, 5 Oct 1999 01:05:15 -0600
>         InformationWeek <news@daily.informationweek.com>
>
>
> - Intel: Itanium It Is, And IBM's On Board
>
> Intel officials said yesterday they've raised with IBM the possibility of
> replacing the chip used to power the company's popular AS/400 server
> line with Intel's forthcoming Itanium processor, which until now has been
> known by its code-name, Merced. While Intel said that IBM hasn't
> committed to using Itanium in the AS/400, it has agreed to transition its
> Pentium-based servers onto the processor beginning next year, when the
> chip ships. "They're interested, but they haven't made a commitment" on
> the AS/400, says Ron Curry, director of marketing for Intel's IA-64
> product group, adding that, "For the Netfinity line, they have."
>
> Currently, the AS/400 runs on PowerPC chips designed jointly by IBM
> and Motorola. Intel, however, claims that the 64-bit Itanium chip, which
> features what the company calls Explicitly Parallel Instruction
> Computing, will be faster than RISC-based PowerPC chips. IBM officials
> weren't immediately available for comment. Along with IBM, other
> companies that have committed to Itanium for at least some of their
> server offerings include Compaq, Dell, and Hewlett-Packard, according to
> Intel.
>
> Intel's comments about IBM were made as the company announced
> Itanium as the official moniker of the often-delayed 64-bit chip.
> Explaining the choice, an Intel spokesman says, "There's the obvious
> association with a very high-tech metal that connotes strength."
> Samples of Itanium are shipping to developers and Intel's OEM
> partners, the spokesman says.  - Paul McDougall
>

Wouldn't this be a step backwards for the 400. Or would they only be
considering it for the very low end?

--
Richard Rosenbluth
Rose Information Management Co.
mailto:rose400@pacbell.net
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.