HP3000-L Archives

September 2002, 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:
Gavin Scott <[log in to unmask]>
Reply To:
Gavin Scott <[log in to unmask]>
Date:
Fri, 6 Sep 2002 15:36:26 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (77 lines)
Bernie asks:
> I have been looking for, and not finding, any MPE to HP-UX
> performance comparisons.

There really aren't (yet) any *application* level performance comparisons
that I'm aware of, though lots of people involved in one aspect or another
of migrating people off of MPE are all working to come up with numbers in
this area, so I would expect to start seeing some numbers for specific
migration products/services in the coming months.

At the level of pure CPU performance, and to some degree things like simple
disk or LAN I/O, performance is pretty much independent of the operating
system you're running.  It's only when you start requesting more complex
services from the operating system (creating processes, manipulating files,
etc.) or start building up applications where different algorithms, tools,
and things like databases are used on each platform that it becomes
difficult to predict the relative performance of, say, a migrated MPE
application.

So unfortunately nobody yet has an answer to the "how fast will my MPE
application run on HP-UX?" question.  To a first approximation you can
probably say that on identical hardware the application will have the same
performance on HP-UX as it does on MPE.  However there are things that will
be slower and things that will be faster due to differences in
implementation and/or your utilization of them, and if your application is
particularly dependent on these things then it could be a lot slower or a
lot faster, and there's really no easy way to tell in advance.

Of course of you're going to convert a "110MHz" A-class MPE system into a
440MHz HP-UX system, then you probably start out with at least a factor of
five in overall improvement in system performance, so chances are good that
the HP-UX version will run "a lot faster" unless someone screws up the
migration really badly :-)

> And can you provide some specifics about how the
> comparisons were done?

I was not directly involved in the testing that pointed out the discrepancy
in the current A-class performance relative to their published
specifications, but I believe the program was a "toy" benchmark written in
COBOL to look for prime numbers.  It was thus purely dependent on CPU
performance.  The test program was compiled with the MPE compiler and then
the object file was linked into a program on both MPE and HP-UX, so the same
object code was run on each system, thus eliminating the effect of using
different compilers.

The resulting programs ran about eight times faster on a 440MHz HP-UX
A-class system than on a "110MHz" MPE A-class rather than the four times one
would expect.

I believe that after that there were some additional tests done that
indicated that I/O throughput was also being affected significantly by
whatever the slowdown mechanism is.  The indication is that the machine
periodically goes to sleep (in a loop or halted or something) during which
time interrupts are ignored until the next time the system "wakes up" and
thus is often unable to respond to hardware I/O completion interrupts in a
timely fashion.  This results in I/O performance that's much worse than one
would expect from even a "real" 55MHz computer (which might be slower to get
things done, but would still be able to respond to interrupts almost
instantly) since disk and network I/O throughput is not normally limited by
CPU performance to any great degree.

Subsequently a test program was written to try to see what was actually
happening.  This program uses only the OS's real-time reporting ability
along with the PA-RISC CPU's "Interval Timer" register that counts hardware
clock cycles to determine the actual clock rate of the CPU in the system and
how many of the available clock cycles the user is being allowed access to.
This program seemed to confirm the approximately 8:1 slowdown ratio
exhibited by CPU-intensive benchmark tests, at least on the systems it has
been run on to date.  I think it's available for download on our web site
somewhere.

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2