91–99 of 99 posts
Earlier quoted context omitted.
I wonder if this was how people felt about C in early days. ASM was the low level frailty, and C the oh-so-clean one-make-away world to create, extend, modify your system.
Lispmachines existed in the early days of C, so no probably not.
Earlier quoted context omitted.
My point was that with dynamic libraries at fixed memory addresses, dynamic linking information can be cached (as long as no binaries are updated). That would imply similar efficiency as for static libraries. Sorry if I wasn't clear.
Isn't that what prelinking[1] does? [1]: http://en.wikipedia.org/wiki/Prelink
Sometimes I regret that, but then I think of the repeated reading of the Effective C++ books. Not to mention the writing of C for a week which I could throw together in hours in Lisp or Perl.
Earlier quoted context omitted.
the whole library gets mmapped, there is no point doing otherwise, the mapping itself is cheap. You are probably talking about demand paging (which happens on statically linked binaries.
You probably talking about Linux, there are other types of dynamic loaders out there.
Earlier quoted context omitted.
I think the real advantage to static linking is that it forces developers to fully acknowledge the resources they are using. Programs using shared libraries allow a degree of avoiding blame. It's difficult to judge the real impact of things, it rests upon assumptions about how much the library is shared, while putting pressure on the library to be serve more masters and to become more generalized increasing overall s…
You still have the same issues about blame with libraries, static linking them won't solve it.
Earlier quoted context omitted.
It's been awhile since I've mucked about with these sorts of things, but I'm glad that my thought about that is confirmed: if static linking only brings in used functions, why doesn't dynamic loading do the same (it does, apparently)? Much of this railing against dynamic loading wasting resources seems like complaining about the wrong things, either bad dynamic linkers, or bad libraries, neither of which will be fixe…
AFAIK static linking doesn't bring in "used functions". It brings in used libraries , all at once. E.g. if you used sincos() from math.a, and math.a contained 47 other math functions, then you'd get all 48 math functions in your static binary just from using sincos(). Someone correct me if I'm wrong but I believe it's only with good whole program optimization at link time that it's possible to truly prove that a func…
Earlier quoted context omitted.
that one paragraph... if i were you i'd be wishing i could edit that comment! you most certainly do not "cut down on file load time." the linking process is a complex task, especially if it's to be performed with any efficiency. i remember when starting a large dynamically linked executable was a glacial process on linux, far slower than the time necessary to read the entire executable from disk. no sensible system l…
To be clear, loading data from disk takes milliseconds and re-computing addresses takes nanoseconds . Yes, in less than one tenth the time it takes to read the part of the libraries you have linked into your binary from disk, you can locate and fixup any link references. This part I don't get "no sensible system loads the entire executable when it's statically linked." If you're a statically linked executable, by def…
I think the literature surrounding prelink pretty strongly contradicts this assertion. See:
http://people.redhat.com/jakub/prelink/prelink.pdf
Ah kids, they crack me up! Lot of fun reading that, I looked around briefly but couldn't find my email archive from Sun, but I was in the kernel group when folks got the idea that "Gee if you shared the text segment of libraries, that would give you more memory for your buffer cache or user pages!" One of the guys in my group re-wrote the linker to scan through and realign text segments so that the maximum number of…
Earlier quoted context omitted.
AFAIK static linking doesn't bring in "used functions". It brings in used libraries , all at once. E.g. if you used sincos() from math.a, and math.a contained 47 other math functions, then you'd get all 48 math functions in your static binary just from using sincos(). Someone correct me if I'm wrong but I believe it's only with good whole program optimization at link time that it's possible to truly prove that a func…
You are wrong... sort of. It brings in used objects . A library can be made up of many objects; unused ones will be discarded.