Newsgroups: comp.sys.hp

> I've got an application running on an HP 9000/710 with 48M of RAM under HP-UX
> 8.07 that is run by up to 80 users at a time (and adding more would always be
> an advantage) each running a separate copy of the application.  I had compiled
> it with the CFLAGS "+O3 +ESlit", which should, according to TFM for cc(1),
> give me the highest level of optimization and put strings in read-only memory
> for better sharing.  This machine uses shared libraries by default, which I
> figured would save me memory.  Due to a couple bugs in the program, I
> recompiled it without the +O3 and used -g instead, and found that it was dying
> somewhere inside a shared library, which didn't tell me much, so I recompiled
> again, this time with the option "-Wl,-a,archive" to the linker, which should
> use the archive libraries instead of the shared libraries.  I figured I would
> be using up more real memory by not using the shared libraries, but am in fact
> using less!  How can this be?!
> 
> So I have two questions...
> 
> 1)  How come NOT using shared libraries allowed my application to use up less
> real memory per process?  If this is so, what is the point of shared libraries?

You may be confusing the concepts of shared executables with shared
libraries.  The Series 700 normally creates a.outs that are shared
executables.  That is, all processes executing the SAME a.out will share
a single text segment in memory.  That text segment will be loaded when
the first using process begins execution and it will be removed from
memory when the last process finishes.  Each process will have its own
versions of the data and bss segments, however.  To minimize the total
amount of memory needed to support many concurrent invocations of the
program, therefore, you should strive to minimize the amount of data,
not the size of the text segment.

A shared library is useful in reducing the size of the a.out, primarily
an advantage in reducing the amount of disk storage for lots of
different executables because none of the library routines are stored
with the executable as part of the a.out.  If you have numerous
DIFFERENT executables that run concurrently but which share the same
library (e.g., libc.sl) then shared libraries can help, too.

Shared libraries are constructed using compiler options which cause
somewhat less efficient code to be generated.  This is necessary because
the code must be relocatable "on the fly" at execution time.  The code
is not only a little slower but also a little bigger for each library
call.  That's why you see the overall memory size grow slightly.

> 
> 2)  How can I compile my application so as to make it share memory better among
> the 80 copies of it that may be simultaneously running?  Is there something
> big I'm missing?  Or would I have to tear it apart and put most of its
> functions in a library of my own creation?  (And would I then want to make that
> shareable or not?)

Minimize the size of your data and bss segments which are unique for
each process.  If you have data that can be shared among processes you
might consider the use of shared memory segments.

An excellent discussion in depth of the difference between shared
executables and shared libraries is contained in "Programming on HP-UX",
part number B2355-90010.  It may contains some further clues for you.

I hope this helps,
Mike McNelly
mike@fc.hp.com
(Not a representative of anybody but myself)
Newsgroups: comp.sys.hp