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

Striking gold in binutils

Striking gold in binutils

Posted Mar 26, 2008 17:37 UTC (Wed) by joey (subscriber, #328)
Parent article: Striking gold in binutils

I feel for the people developing software where a 5x linker speedup is valuable. Really...
I've watched your code build natively on some slow arm machines where linking took 20 hours.

Will this really be a big win for most of us? I hope not. Things that take significant time to
link tend to be big messes.

Now automake and libtool -- that's slow for all of us..


(Log in to post comments)

Striking gold in binutils

Posted Mar 26, 2008 17:53 UTC (Wed) by elanthis (guest, #6227) [Link]

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.

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.

Striking gold in binutils

Posted Mar 26, 2008 19:35 UTC (Wed) by aleXXX (subscriber, #2742) [Link]

> Will this really be a big win for most of us? I hope not. Things that
> take significant time to link tend to be big messes.

Hmm, if you have applications which link to a big number of libraries 
with many symbols (e.g. KDE) linking does take quite long, so improving 
this may be really nice.
I'll give it a try.

> Now automake and libtool -- that's slow for all of us..

Just use cmake, it does it all and also gets rid of libtool :-)

Alex


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