Sponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Striking gold in binutils
Striking gold in binutils
Posted Mar 26, 2008 17:53 UTC (Wed) by elanthis (subscriber, #6227)In reply to: Striking gold in binutils by joey
Parent article: Striking gold in binutils
C++ programs tend to generate a huge number of symbols. Things like Firefox and OpenOffice.org are pure hell to build. There's also the issue of simply large programs written in other languages, or collections of programs. Shaving 2 seconds off link time may not seem like much, but when you're compiling several dozen executables in one go, that 2 seconds adds up really quick.
(Log in to post comments)
Striking gold in binutils
Posted Mar 26, 2008 19:18 UTC (Wed) by mto (subscriber, #24123) [Link]
Won't this, in the long run, affect load times for applications? dynamically linked applications need to be linked twice: once right after compile, and a second time at run time. If gold could eventually replace ld.so and run 5 times faster, the impact is pretty big...
Striking gold in binutils
Posted Mar 26, 2008 20:44 UTC (Wed) by nix (subscriber, #2304) [Link]
It can't replace ld.so. The dynamic and static linkers have quite different (although related) jobs, and have very different goals as well (e.g. performance is utterly paramount for ld.so but less so for ld). The only system which has even *tried* to merge the two is AIX, and I think even it gave up in the end.
Striking gold in binutils
Posted Mar 26, 2008 19:58 UTC (Wed) by nix (subscriber, #2304) [Link]
It's not just 'a huge number of symbols'; it's 'a huge number of symbols with very long names differing only in their last few characters'. This also proved to be a worst-case for a lot of dynamic linkers...
Striking gold in binutils
Posted Mar 27, 2008 7:17 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
Is this really the case? I once tried hacking up ld.so to do the lookup backwards (it is actually possible without doing a strlen for every comparison) and I could see no difference in performance, based on loading OpenOffice with both linkers and enabling the built-in linker profiling. Of course, I may have messed up something else in the process...
ld.so is different beast
Posted Mar 27, 2008 9:43 UTC (Thu) by khim (subscriber, #9252) [Link]
You can read about what goes on there in Drepper's article. Scroll down to "The GNU-style hash table".
ld.so is different beast
Posted Mar 27, 2008 10:16 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
That article was the reason I tried it in the first place :)
Striking gold in binutils
Posted Mar 27, 2008 10:46 UTC (Thu) by nix (subscriber, #2304) [Link]
Hm, interesting. I'll try it at some point (probably with part of KDE: OOo takes too damn long to build ;} ) and see if I can make it go slow ;}
Striking gold in binutils
Posted Mar 27, 2008 11:05 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
No need to rebuild anything to try out a new dynamic linker, methinks...
Striking gold in binutils
Posted Mar 28, 2008 21:27 UTC (Fri) by nix (subscriber, #2304) [Link]
I need to rebuild it to add back a non DT_GNU_HASH :)
Striking gold in binutils
Posted Mar 28, 2008 16:26 UTC (Fri) by landley (subscriber, #6789) [Link]
A friend of mine who still bothers with C++ explained to me once how C++ compilers used to use a linker optimization where the name mangling would put the innermost identifiers first, and the outermost identifiers last. That way if you had these two symbols: class1.class2.class3.class4.member1 class1.class2.class3.class4.member2 By comparing "member1" vs "member2" first, your string match would figure out inequality faster. If you go the other way, your string matches have to go through lots of common namespace for every symbol before coming to the unique parts, and with BigLongMixedCaseNames this can get fairly ridiculous. Now, which way did the Intel Itanium C++ spec specify that name mangling had to occur? The long way that links slowly, of course. And everybody else picked up the Itanium C++ spec because nobody else bothered to write up a standard for this part of the language.