T.R | Title | User | Personal Name | Date | Lines |
---|
1454.1 | | DCEIDL::BUTENHOF | Dave Butenhof, DECthreads | Tue Dec 17 1996 09:34 | 6 |
1454.2 | thanks and ... | HYDRA::PASHAPOUR | Disk space, the final frontier | Tue Dec 17 1996 12:44 | 10 |
1454.3 | | DCEIDL::BUTENHOF | Dave Butenhof, DECthreads | Tue Dec 17 1996 13:32 | 24 |
1454.4 | Agreed! | HYDRA::PASHAPOUR | Disk space, the final frontier | Tue Dec 17 1996 14:47 | 7 |
1454.5 | | VAXCPU::michaud | Jeff Michaud - ObjectBroker | Tue Dec 17 1996 20:56 | 2 |
1454.6 | | DCEIDL::BUTENHOF | Dave Butenhof, DECthreads | Wed Dec 18 1996 08:53 | 18 |
1454.7 | | HYDRA::SCHAFER | Mark Schafer, SPE MRO | Wed Dec 18 1996 12:07 | 9 |
1454.8 | So where are shared libs documented? | APACHE::CHAMBERS | | Thu Dec 19 1996 14:57 | 45 |
1454.9 | You had the right idea | WIBBIN::NOYCE | Pulling weeds, pickin' stones | Thu Dec 19 1996 16:52 | 2 |
1454.10 | It's -shared on the ld command | EDSCLU::GARROD | IBM Interconnect Engineering | Thu Dec 19 1996 17:08 | 12 |
1454.11 | | VAXCPU::michaud | Jeff Michaud - ObjectBroker | Thu Dec 19 1996 18:22 | 19 |
1454.12 | Am I missing somthing? | FREE::CAMBRIA | We're just one PTF from never talking to VTAM again | Fri Dec 20 1996 13:06 | 16 |
1454.13 | Then what ? | APACHE::CHAMBERS | | Fri Dec 20 1996 18:35 | 10 |
1454.14 | Z | netrix.lkg.dec.com::thomas | The Code Warrior | Fri Dec 20 1996 21:12 | 3 |
1454.15 | | VAXCPU::michaud | Jeff Michaud - ObjectBroker | Fri Dec 20 1996 21:24 | 8 |
1454.16 | So where's this documented? | APACHE::CHAMBERS | | Tue Dec 24 1996 12:34 | 39 |
1454.17 | | VAXCPU::michaud | Jeff Michaud - ObjectBroker | Tue Dec 24 1996 19:21 | 25 |
1454.18 | a few more items... | HYDRA::KENYON | The Foundation of Science...Fiction | Thu Jan 02 1997 18:11 | 20 |
1454.19 | help me understand the maintenance cost... | HYDRA::KENYON | The Foundation of Science...Fiction | Thu Jan 02 1997 18:18 | 17 |
1454.20 | | DCEIDL::BUTENHOF | Dave Butenhof, DECthreads | Fri Jan 03 1997 10:40 | 14 |
1454.21 | Why the cost is so high (or, at least, the technical side of it...) | WTFN::SCALES | Despair is appropriate and inevitable. | Fri Jan 03 1997 17:03 | 37 |
1454.22 | While I'm at it... :-) | WTFN::SCALES | Despair is appropriate and inevitable. | Fri Jan 03 1997 17:28 | 41 |
1454.23 | got it... | HYDRA::KENYON | The Foundation of Science...Fiction | Fri Jan 03 1997 19:57 | 23 |
1454.24 | | VAXCPU::michaud | Jeff Michaud - ObjectBroker | Sat Jan 04 1997 00:52 | 44 |
1454.25 | | SMURF::DENHAM | USG | Mon Jan 06 1997 13:21 | 15 |
1454.26 | OM and static libraries anyone? | MIASYS::ENGLAND | | Wed Mar 05 1997 11:27 | 13 |
| 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-
|
1454.27 | Penny-wise and pound-foolish...unless you really need it. | WTFN::SCALES | Despair is appropriate and inevitable. | Wed Mar 05 1997 13:29 | 20 |
| .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
|
1454.28 | why performance vs shared libraries? | MIASYS::ENGLAND | | Mon Mar 10 1997 18:50 | 13 |
| 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-
|
1454.29 | A WAG. | WTFN::SCALES | Despair is appropriate and inevitable. | Mon Mar 10 1997 21:50 | 14 |
| .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
|