Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sta.li: Static Linux

sta.li

Post reply on HN
Print view View original

71–80 of 99 posts

Re: Sta.li: Static Linux

#71

Post by clord »

pjmlp wrote: post #30
clord wrote: post #26

Earlier quoted context omitted.

On top of what others have said, it takes some time to dynamically load a library into an address space. There are tables that may need to be walked and updated with correct pointers. For large libraries, this can be quite measurable. A statically linked executable will be memory-mapped and then brought in lazily as the program runs. And then if executed again, everything is mapped and loaded, so there is zero delay.…

How many minutes are saved by 10-20% faster? A few seconds don't matter for a human.

We have some scripts at work that take 10+ hours to execute. Granted most of that time is in large child processes.

Re: Sta.li: Static Linux

#72

Post by npsimons »

pjmlp wrote: post #29
cgh wrote: post #17

Earlier quoted context omitted.

Static linking doesn't necessarily link the entire library, unless the entire thing compiles to a single .o file. Linkers are smart enough to only link in the object files needed by the program. So assuming you are only linking in well-designed libraries, I guess it's possible that statically-linked software will be smaller since it will leave out the stuff you aren't using.

> So assuming you are only linking in well-designed libraries This is a very big assumption. Dynamic linkers are also clever enough to only mmap the required parts of dynamic library.

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 fixed by static linking.

Don't get me wrong, there are places I think that static linking is ideal. I wish more distributors of binary only software would statically link, or at least include standalone required dynamic libraries, rather than rely on system dynamic libraries.

I wish them luck in their experiment and hope they can improve static linking, but I suspect they will learn more about why dynamic loading "wastes" so many resources the more they come in contact with real world libraries.

Re: Sta.li: Static Linux

#73

Post by Jare »

spc476 wrote: post #28
cgh wrote: post #17

Earlier quoted context omitted.

Static linking doesn't necessarily link the entire library, unless the entire thing compiles to a single .o file. Linkers are smart enough to only link in the object files needed by the program. So assuming you are only linking in well-designed libraries, I guess it's possible that statically-linked software will be smaller since it will leave out the stuff you aren't using.

I recently played around with this, taking a rather small project (around 15,000 lines of code), putting it all into a single file and compiling. It did produce a smaller executable, but the real gain was in making every function static (since it's all in a single file). Doing that, a total of 41 functions were eliminated (either inlined or not used at all). Was it worth the effort? Eh. But it was instructive and I'd…

That approach is common practice when developing for game consoles.

Re: Sta.li: Static Linux

#74

Post by BugBrother »

nteon wrote: post #70
BugBrother wrote: post #68

Earlier quoted context omitted.

>>the linking process is a complex task, especially if it's to be performed with any efficiency. I'm no kernel hacker, but doesn't that make the GP argument better? It would be almost like static linking? If code is compiled against a shared lib which always will be at the same address in virtual memory, a linking setup could be cached. (And redone if there is a new version of the library, of course.) (I realize that…

>> I'm no kernel hacker, but doesn't that make the GP argument better? Nope. Dynamic linking is done each time the program is loaded - the kernel calls out to the dynamic linker to open shared libraries, resolve symbols, create jump tables & the like. Static linking is done once (at compile/link time). When you execute a statically compiled library, the kernel just loads the text, data & bss into memory and more or l…

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.

Re: Sta.li: Static Linux

#76

Post by lmz »

BugBrother wrote: post #74
nteon wrote: post #70

Earlier quoted context omitted.

>> I'm no kernel hacker, but doesn't that make the GP argument better? Nope. Dynamic linking is done each time the program is loaded - the kernel calls out to the dynamic linker to open shared libraries, resolve symbols, create jump tables & the like. Static linking is done once (at compile/link time). When you execute a statically compiled library, the kernel just loads the text, data & bss into memory and more or l…

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

Re: Sta.li: Static Linux

#77

Post by ithkuil »

BugBrother wrote: post #74
nteon wrote: post #70

Earlier quoted context omitted.

>> I'm no kernel hacker, but doesn't that make the GP argument better? Nope. Dynamic linking is done each time the program is loaded - the kernel calls out to the dynamic linker to open shared libraries, resolve symbols, create jump tables & the like. Static linking is done once (at compile/link time). When you execute a statically compiled library, the kernel just loads the text, data & bss into memory and more or l…

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.

furthermore the most dramatic issues arise with C++ vtables, although even that has been addressed with prelinking and a large address space helps a lot.

Re: Sta.li: Static Linux

#78

Post by ithkuil »

pjmlp wrote: post #29
cgh wrote: post #17

Earlier quoted context omitted.

Static linking doesn't necessarily link the entire library, unless the entire thing compiles to a single .o file. Linkers are smart enough to only link in the object files needed by the program. So assuming you are only linking in well-designed libraries, I guess it's possible that statically-linked software will be smaller since it will leave out the stuff you aren't using.

> So assuming you are only linking in well-designed libraries This is a very big assumption. Dynamic linkers are also clever enough to only mmap the required parts of dynamic library.

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.

Re: Sta.li: Static Linux

#79

Post by hnisnotreddit »

GFK_of_xmaspast wrote: post #25
cgh wrote: post #18

I enjoyed this from their description of their dwm window manager, which took me back to the general state of Linux circa 1999: "Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though."

I don't miss the general state of linux circa 1999 one bit.

I, for one, miss spending 10 hours fully compiling GNOME 0.99.8 and Englightenment 0.15 from CVS every week on my Pentium 133 running Linux Mandrake.

Over the past 17 or so years I've been using linux full-time, I've experienced 3 or 4 of the "sweet spots", or times where using linux was superior to everything else on the market. GNOME 1.x with Enlightenment 0.15 (vs Win98) was the second one (the first, I'm told, was E DR0.13 with CmdrTaco's task managing app and Hand of God theme vs Win95). I believe we are currently at the end of another sweet spot with KDE 4.x being put out to pasture, as it completely destroys the UX of Windows 7/8 and Mountain Lion.

But don't knock the state of linux circa 1999. Sure, you had to ensure your sound cards had OSS drivers, and Winmodems sucked, but it was a superior experience to Win9x even back then.

Re: Sta.li: Static Linux

#80

Post by ChuckMcM »

nteon wrote: post #70
BugBrother wrote: post #68

Earlier quoted context omitted.

>>the linking process is a complex task, especially if it's to be performed with any efficiency. I'm no kernel hacker, but doesn't that make the GP argument better? It would be almost like static linking? If code is compiled against a shared lib which always will be at the same address in virtual memory, a linking setup could be cached. (And redone if there is a new version of the library, of course.) (I realize that…

>> I'm no kernel hacker, but doesn't that make the GP argument better? Nope. Dynamic linking is done each time the program is loaded - the kernel calls out to the dynamic linker to open shared libraries, resolve symbols, create jump tables & the like. Static linking is done once (at compile/link time). When you execute a statically compiled library, the kernel just loads the text, data & bss into memory and more or l…

BugBrother however correctly interpreted my suggestion, which is that given a large address space, one could define an address where shared libraries would always appear. Thus your linking information can be fixed in in the executable and the only dynamic part is a check to see if the library is loaded or not. Thus all the link speed benefits of static linking, the load speed benefits of dynamic linking.
Post reply on HN