Thanks Ben, and thanks too for (separately) reminding me that I posed
this same question on the mailing list 2-3 years ago (a few octave
upgrades ago) ... I guess I'm headed for old geezerdom, forgetting the
questions I already asked, the stories I already told etc. Better than
some of the alternatives I suppose.
Anyway, thanks again everybody.
Judah
On 5/25/25 22:11, Ben Stern wrote:
On Sun, May 25, 2025 at 08:07:04PM -0400, J. Milgram wrote:
Since the real objective here is to try out Open BLAS, I dusted off my
ancient rotorcraft code - all F77 - and tried linking it two ways:
1) -llapack -lopenblas
In this case lapack.so itself was built against libopenblas.
2) -L./lapack -L./blas -llapack -lblas
builds only mini static versions of lapack and blas with just the required
routines, using the supposedly-slow netlib reference implementations.
#1 should be faster, right?
However, #2 produced an executable that ran a smidgen faster.
How about that. Maybe it does some inlining that's not possible when one
links dynamically? Just a hypothesis.
This is what we call low-priority goofing off.
I'm guessing the time to load the larger "statically-linked" binary exceeded
the runtime cost of resolving/opening the linked libraries.
A properly optimized static link *should* be faster than the dynamic link
resolution and opening and symbol table matching up and stuff, but I haven't
grovelled through that stuff in more than a decade.
If my life depended on it, I'd say it had something to do with the ratio of
the size of symbols in the shared library to the size of (code + data) in
the (shared or static) library, and if link-time-optimization didn't throw
away enough of the (code+data) in the static library, it would cost more
time to read through the (code+data) in the static binary vs just reading
symbol tables in the shared libraries.
On a tangent, I've read that GNU libc is bad at static linking and something
something your static binaries still have a runtime dependency on libc.so,
but I can't find the reference for it right now, so it should be treated as
a myth to scare small children at best.
Ben
--
=====
milg...@cgpp.com
301-257-7069
You received this email because you are subscribed to the UM Linux User's Group
(UM-LINUX) mailing list. If you would like to unsubscribe from this list,
simply send an email to lists...@listserv.umd.edu with the message signoff
UM-LINUX in the body.
