HP3000-L Archives

May 1998, Week 3

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:
Jeff Vance <[log in to unmask]>
Reply To:
Jeff Vance <[log in to unmask]>
Date:
Wed, 20 May 1998 16:50:08 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (61 lines)
On May 20, 12:57pm, Kathy McCarthy wrote:
...
>         1.) assuming HP will eventually provide this technology in the
>         HP3000, will the benefits be the same, greater, or less than on
>         the 9000?

The initial releases of 64 bitness in MPE will differ from hp-ux in some
external ways:
  - There will not be a 64 bit developers environment (compilers, debuggers...)
This means that you do not need modify your app to run on MPE with 64 bitness.
The 64 bit features will be internal and allow us to support files up to 1 TB
and larger physical memory and larger objects.

  - There will not be mirrored 64 bit APIs (MPE intrinsics).  Again this
means that you do not need to re-engineer the applications and tools that
you are using on MPE.  It also means you do not have direct access to MPE's
64 bitness.  It is currently a fairly large effort to get apps to hpux 11.0
in wide mode, i.e. using the 64 bit environment.

- The SOM (executable) format is still used  vs. converting to ELF-64 as in
hp-ux.  Again no impact to you or 3rd parties.

>         2.) what will be the impact on third party software providers? I
>         assume some changes would need to be made to the programs in order
>         to benefit from 64-bit computing.  Is this a large or minimal
>         effort on their part? (I would expect that, if it were a major
>         investment, those providers might balk at making the investment,
>         unless they thought there was a significant market potential.)

There should be no effort to most third parties.  The exceptions would
be tools vendors that have intimate knowlege of the OS and some of its lower
level data structures.  We will be (and are) working with these 3rd parties
to ensure that their products run well on the intial release of MPE that
supports 64 bits.

>         3.) which brings up the next question: are the benefits of 64-bit
>         computing likely to be applicable to just large shops, or will
>         smaller operations see enough benefit to warrant paying to upgrade
>         their machines and application software?

The main benefit of MPE 64 bit computing are:
  a. faster memory to memory moves, which are common in the OS
  b. support of large internal objects (data structures)
  c. due to b. we can support more physical memory, so if your apps
     run faster with more memory then this will improve their performance.

A drawback of 64 bitness in wide mode (that is, 64 bit address offsets, or a
flat 64 bit address space) is that performance generally gets worse.  The
reason is that most apps don't need 64 bit addresses but they will be
using them and the associated extra space.  These wider addresses consume
more cache space, which menas there are less unique addresses we can have
in the cache.  This causes us to have more cache misses which results in
in more OS overhead to translate virtual address to real addresses.  AKAIK,
hp-ux 64 bit benchmarks will be done in "narrow" 32 bit mode.  Narrow mode is
only mode initially supported by MPE

Hope that helps some,
Jeff Vance, CSY

--

ATOM RSS1 RSS2