User: Password:
|
|
Subscribe / Log in / New account

Striking gold in binutils

Striking gold in binutils

Posted Mar 26, 2008 17:53 UTC (Wed) by elanthis (guest, #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 (guest, #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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds