Daniel Kosack wrote:
> > ... So developers rely on launching a lot of
> > processes. But again, this doesn't scale well.
>
>   How fast should it be?  It needs to allocate memory, check permissions,
> limits, etc.  To go any faster would be to possibly risk POSIX
> compliance, and hence get rid of why UNIX is what it is.
 
Which may be a good thing or a bad thing, depending :-). Actually, the point
was that it's fast enough for small applications, but that developers should
have come up with different ways of handling large applications.
 
> > These two programs perform the same functions, but HP's implementation,
> > optimized to take advantage of things MPE does well (and avoid the ones it
> > does poorly) runs several times faster.
>
>   A program such as a web server, for the most part, is a collection of
> library and intrinsic calls.  Perhaps it is HP's lack of optimization in
> the POSIX development areas that cause this performance degradation in
> the first place?
 
I suppose you could chalk it up to a lack of optimization. On the other hand,
the lack of optimization is due to engineering trade-offs made in other areas.
MPE's file system has far more features than the Unix file system, many of
which can't be emulated on Unix except at great cost. The best example is
controlled file sharing. When a process opens a file under MPE, that process
can specify whether the operating system is to permit no concurrent access,
concurrent access only for readers, concurrent access for everybody (the Unix
model), and/or concurrent access only by those processes that agree to
cooperate by locking the file when necessary. The process can also specify
whether the file pointer and buffers for a file should be shared among all
processes, shared among processes in the same process tree, or private to each
process (the Unix model).
 
There are two consequences of this flexibility that are important to httpd
(and to programs designed like httpd). First, opening a file under MPE takes
longer than it does under Unix. There's more to keep track of, and more things
to check. Second, Unix's fork() semantics don't make sense in some cases under
MPE. What does it mean to fork() a process that has a file open for exclusive
access, for example? The data structures required to maintain this rich access
model take a lot of time to clone. The same applies to other shared resources.
Hence, fork() is slower on MPE than it is on Unix. Since httpd relies a lot on
fork() and fopen(), it's going to be slower under MPE than a program with
equivalent functionality that doesn't rely so much on these functions. (And it
would be slower even if it used "MPE native" equivalents like HPFOPEN and
CREATEPROCESS.)
 
On the other hand, by coding the application to take advantage of MPE's
strengths, the performance _can_ be better than it is under Unix. The cost is
somewhat increased application complexity, because state information must be
maintained by an MPE application between transactions, while in the typical
Unix model a fresh process is created per transaction and thrown away when the
transaction has ended, so no state preservation is necessary.
 
This isn't a criticism of either OS; it's simply a statement of the design
tradeoffs made by the original system architects.
 
-- 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