Re: packaging static lib oriented software
Mark Baker <mbaker@iee.org> wrote:
> Assuming the reason for the slowdown is the use of an extra register,
> it obviously depends on what you're doing.
Sure, to pull a couple examples out of a hat: consider a math library
which provides operations on complex numbers. The routine to do
matrix inversion is going to spend most of its time in the library
while the routine which does cosine is going to spend very little of
its time in the library.
But it strikes me that we're solving the wrong problem here (in the
sense of trying to provide a good design). It should not be necessary
to have a policy *requiring* that a package be implemented in some
certain fashion. We should be providing an environment which can
mix&match implementation techniques as needed for good performance.
That said, I think I can see several obstacles:
(1) compiler technology (just how do you compile a program so that the
library has an fpic interface but selected hot-spots
from that library get linked statically)? Is this even possible in
elf, or do we have to have a separate library for each routine, with
a shared and a static version of each (worst case I can think of)?
(2) computer literacy, and schedule crunches (how much are we expecting
from our maintainers, and/or from the original software authors)?
Benchmarks are hard if you're not in the right frame of mind, ferinstance.
Also, remember Knuth, he's sometimes right (e.g. "Premature optimization
is the root of all evil").
(3) documentation (just try and come up with easy to understand
documentation adequately covering all the issues).
--
Raul
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: