Re: Unfortunate dynamic linking for everything

M. Warner Losh said:
> In message: <200311181307.hAID7uHa032514_at_dyson.jdyson.com>
>             dyson_at_iquest.net writes:
> : 	It really doesn't make sense to arbitrarily cut-off a
> : 	discussion especially when a decision might be incorrect.
> 
> I'd say that good technical discussion about why this is wrong would
> be good.  However, emotional ones should be left behind.  Except for
> John's message, most of the earlier messages have been more emotional
> than technical.
> 
> John, do you have any good set of benchmarks that people can run to
> illustrate your point?
> 
I'll see if I can find some of my old benchmarks (from memory,
not disk -- lots of stuff has rotted away.).  I had hoped
to avoid doing much in the way of proof.  Pointing to the
much more complex process map along with the implication
for significantly higher overhead :-).  (The VM code generally
gets slower with more complex process maps and more memory used.
For smallish programs -- including those with a few shared libs,
changing the VM code won't help much, because the cost is built
in to the complexity of the process image.)

If set-up correctly (trying to find facts, rather than proving
a foregone conclusion), even the fork/exec
tests on LMBENCH can be informative.  The LMBENCH fork/exec benchmarks
don't really measure EVERYTHING, and there appears to be a
additional overhead beyond the old-time a.out, but they
will likely still show some of the additional overhead.  (Actually,
simple fork/exec tests of simple programs don't show all of the
additional overhead, and also bias the overhead results, but
are one data point.)

There might be a certain 'coolness' WRT dynamically linking everything,
but the overhead is certainly measurable.  If the object is to
maximally 'share', then for shells the FreeBSD VM shares maximally
without using shared libs (perhaps there is a lost know-how about
how aggressively the FreeBSD VM implements parent/child and exec
based sharing?)

I'll try to put together a few simple benchmarks -- mostly from my
defective memory.  I had recently refreshed myself on this issue
(but lost again due to disk hardware disasters and being
clobbered by vinum problems -- which I have given up on.)  Gimme
a day or so -- I have several other things in my queue.

John