HP3000-L Archives

February 1997, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Bruce Toback <[log in to unmask]>
Reply To:
Bruce Toback <[log in to unmask]>
Date:
Fri, 7 Feb 1997 10:01:47 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (65 lines)
Ron Seybold writes:
>Remember 10 years ago? HP introduced RISC on the HP 9000s first, nearly a
>full year ahead of the HP 3000's first 32-bit operating system, MPE/XL 1.0.
>And even that head-start wasn't enough. Some who lived through a MPE/XL 1.0
>production implmentation had to acquire great resume skills -- or
>tremendous patience watching their mailboxes for new versions of the
>operating system that would stay up through a full shift...

>After my infamous tilt at this 64-bit windmill last spring, I'm comfortable
>with leaving the HP-UX folks to do the arrow-in-the-backside pioneering
>with 64 bits. Too many people I've talked with couldn't weather the trials
>of getting a new operating system on its feet.

I must respectfully disagree. MPE/XL 1.0 was, for all practical purposes,
an entirely new operating system running on an entirely new architecture.
Customers who went to MPE/XL 1.0 got to try out a million or so lines of
brand-new code, and found some problems along the way.

By contrast, a 64-bit version of MPE might have a few percent of the code
changed, and very little new logic. It's much more an evolutionary than a
revolutionary change. What's more, the entire industry has a lot more
experience with these kinds of transitions. Apple, Dec, HP (twice) and
IBM have all been through CISC-to-RISC transitions. Everybody writes code
that's less platform-dependent -- even OS code -- and is much more
concious of porting issues. That's not to say that a 32- to 64-bit
transition will be a doddle, but it's a couple of orders of magnitude
less difficult than MPE/V to MPE/XL.

Even so, I agree that a 32- to 64-bit transition is less likely to result
in dramatic performance improvements for MPE/iX customers than the press
hype would have us believe. Many of the steps required for fast business
data processing have already been taken: 128- and 256-bit memory buses,
wider and deeper caches, faster memory cycle times. Widening the CPU data
path and increasing the address space will have a less significant
effect. It certainly isn't the case that a transition from 32- to 64-bits
will double the performance of present systems, all other things being
equal.

>Once the customer demand
>overtakes the "supply-driven (i.e., vendor-based)" marketing, we'll need HP
>to get to work on delivering a full 64-bit MPE/iX...

The problem is that without some indication of the kinds of performance
benefits that can be expected from the migration, nobody will know
whether to "demand" 64-bit MPE or not. And it's not an all-or-nothing
proposition, as CISC-to-RISC was. An evolutionary strategy, starting with
a 64-bit file system, makes a lot of sense. We may even have the time to
see it through: I'm prepared to believe that after the last couple of NT
debacles -- including a security flaw that makes it possible to take down
an NT server anywhere on the Internet, router filters or no
(<http://www.infoworld.com/cgi-bin/displayStory.pl?970131.wbug.htm>) --
IT managers are more willing and able to stand up against the kind of
feature-article-in-Fortune-Magazine-driven change that's plagued HP 3000
users for the last 15 years.

-- Bruce


--------------------------------------------------------------------------
Bruce Toback    Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc.            (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142      | But ah, my foes, and oh, my friends -
Phoenix AZ 85028                   | It gives a lovely light.
[log in to unmask]                   |     -- Edna St. Vincent Millay

ATOM RSS1 RSS2