Jeff Kell ([log in to unmask]) wrote:
: With the advent of MPE/iX 5.0 many applications have been ported over
: to the 3000 that traditionally ran on Un*x boxes.  Has anyone compared
: performance of a given package, available on 3000 or 9000, running on
: equivalent processors?
 
: Those results could be interesting...
 
I'll concur that they would be interesting.
 
While portability is nice because it allows us to expand our application
base, it is also a problem in that applications written specifically
for UNIX are generally not optimized for an MPE environment.
 
There are many examples of unix-isms which are somewhat problematic on
MPE.  fork() is one.  The use of globals all over the place is another.
MPE had abandoned globals 10 years ago, and now, for portability, we have
to introduce them.  There are a lot of problems that arise in accomodating
UNIX's globals.  Another problem for MPE is UNIX style IO.  MPE IO and UNIX
IO are about as radically different as they possibly could be.  All of the
ported applications have to go through a extra layers which translate UNIX
style IO into MPE IO.  A few of the less common "translations" aren't
implemented yet- but that is another story.
 
So what does this mean when comparing equivalent MPE hardware to equivalent
UNIX hardware?  It means that a straight port is unlikely to initially perform
better on MPE.  However, if the port includes a few extra changes to better
optimize the application for MPE, this performance difference can be
overcome.  As an example, I ported the WWW server.  I've written a few
benchmarks (simple and incomplete) to test performance.  I haven't benchmarked
a UNIX server, so I can't compare directly.  But I have benchmarked the
straight port against a new version I'm working on which has some MPE
specific enhancements.  The performance is considerably higher.
 
Another consideration when comparing UNIX performance with MPE performance is
the language differences.  MPE has a lot of code in pascal, which does
all kinds of additional trap checking which C doesn't do.  The effect of
this checking is that pascal code will run slower.  It also catches a heck
of a lot of bugs and problems which C would gladly accept.  So, the pascal
vs. C debate is another tradeoff- reliability vs performance.  Of course,
ported C applications are not affected by this directly, but if they
call lower level OS routines which do use pascal code with traps enabled,
it can affect performance.
 
Anyway, I'm probably rambling too long already.
 
Mike
 
---
Mike Belshe
[log in to unmask]
HP CSY Networking Lab