This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: parallelized 'ld'?


Cynbe ru Taren <cynbe@muq.org> writes:

> (Sorry for delayed reply -- I've been swamped by other stuff.)
>
> I've chatted with another of our engineers (Alexander Smundak,
> asmundak at cisco dot com) and it appears that my presumption
> that 'ld' &kith would already be well-tuned at the monoprocessor
> level is untrue, at least for programs in the 1-10 megaline size
> range:  Use of algorithms and datastructures which do not scale
> well into this range appears to be a pervasive problem.
>
> In this particular case, expanding one fix-sized hash table
> bfd_hash_table) from 4K to 64K slots chopped our link time down from
> 3.5 to 1.5 minutes: We were getting hashtable chains literally
> hundreds of items long, resulting in exactly the sort of linear search
> behavior that hash tables are supposed to avoid.  (Yes, I'm mailing a
> more specific report to bug-binutils@gnu.org.)

As DJ points out, this is largely a matter of inadequate developer
time to work on these problems, and any patches you care to contribute
would be much appreciated.

Replacing fixed-size hash tables with calls to the generic expandable
hash table implementation in libiberty (include/hashtab.h) is easy and
should thoroughly squelch that problem.

DWARF2 debug information can be much more compact than stabs *if*
proper size optimizations are implemented, which to date they have not
been, but serious work has been done.  Talk to Dan Jacobowitz.

> * "make generates either too much output or no output at all. This leads to
>    people developing half-baked solutions such as
>       if QUIET=1, echo "Compiling foo.c..."
>    Jam (make alternative) uses IMHO way better approach: by default, it
>    prints just the name of each target as it was built; if build fails,
>    it prints the offending command."

Makefiles that don't print every command exactly as executed are
abominations.  It's only "too much output" when you don't need it, and
you typically find out you need it after it's too late to turn on
verbose output.  Not to mention the joy of digging through the
makefile to figure out the necessary incantation.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]