Conference clt::cma

    I've really enjoyed this discussion immensely (as I mop the blood off
    the floor).  Here's a different point of view to consider.  In recent
    years we've seen the development of OM, a DUX link-time optimizer which
    among other things re-arranges  procedures within the executable or
    even inlines them in the name of  performance.  I can't claim to be an
    OM expert, but it is limited to operating on static libraries.  Perhaps
    some of you have more experience with OM and can tell me whether there
    is enough of a performance "win" with it to justify the use of static
    libraries  for this purpose.  Or are the CPU caches so effective at
    dealing with shared libraries now that we're being penny-wise and pound
    foolish to use static libraries?
    
    -ben-

.26> penny-wise and pound foolish to use static libraries?

It depends on your requirements.  If you have a business need for
"performance at all costs", then obviously it would be foolish -not- to use
static libraries (as long as they continue to provide a performance advantage
over shared ones) and just absorb the downsides as the "cost of doing
business" in your market.

On the other hand, if the performance of your application is adequate when
built with shared libraries, then, yes, it would be foolish to use static
libraries.

Over time, the situation will improve:  we'll get faster processors and
better caches; hopefully soon there will be an OM for applications using
shared libraries; and maybe, just maybe, shared library performance itself
will improve.  So, unless you really need the marginal performance edge (and
are willing to pay the costs), you should use shared libraries.


				Webb

    Could someone explain to me why performance must suffer at all if
    we use shared libraries?  Not knowing OSF internals that well,
    I would naively think that on a 10-CPU machine like the one I'm
    running my current benchmark on, the CPU's instruction cache would
    be more effective with shared libraries.   Why? Because there is
    physically only 1 copy of the code in memory, so there should be 
    a greater probability that the shared library code is in the CPU's
    cache already.  What's wrong with this picture?
    
    thanks
    
    -ben-
    

.28> What's wrong with this picture?

I'm not sure that there's any regular reader of this conference who can answer
your question authoritatively, but...

The biggest difference is that the code calling the shared library is separately
linked from the shared library, so there has to be some "glue" that makes a call
between them possible, independent of the location in memory where the shared
library gets loaded.  My expectation is that the majority of the performance
difference can be traced to how symbol relocation is handled, but that's mostly
a WAG.


				Webb