Slow linking for ARM

Bill Pringlemeir bpringle@sympatico.ca
Fri Dec 24 22:00:00 GMT 2010


On 24 Dec 2010, titus@v9g.de wrote:

> My problem with the absolute linking time of some of my programs for
> ARM is also solved by using ld of a recent binutils.

> My main question (out of curiosity) was why linking for ARM might be
> slower than for other archs.  Also gold exhibits that behaviour, as
> I found out yesterday: Linking the same application for ARM takes
> about 20-30% longer than for X86 and PPC.

> Any ideas what makes ARM different for the linker?

Ok.  Now you are saying 20-30%, I thought it was 20x as long
previously, but maybe you said 20%?

From: "Titus von Boxberg" <titus@v9g.de>
Date: Tue, 21 Dec 2010 11:58:22 +0100
Message-ID: <5bf6e55b8d138530dafd830331163a7c.squirrel@tschetwerikow.v9g.de>

> Linking the same software is about 4 times slower for ARM than for
> the other CPUs.

Earlier, it was 4x.  Is this due to gold/non-gold?

> The resulting executable is biggest for PowerPC, so that cannot be
> the reason; also the differences in size are not large enough to
> explain the time figures.

The PPC has 32 registers.  The ARM makes all instructions conditional,
the X86 has variable instruction size.  If you are comparing the
binaries, of different architechures, it is not really fair.  I have
observed that compressing the binaries on different architectures will
result in the same size files.  If not, then something is possible not
being excluded with the linker.  Ie, the PPC instruction set is not as
dense as the ARM and x86, but they usually have the same amount of
'information' which is reflected in the original source code.

There certainly could be architectural differences between the ARM and
the other architectures.  Different compile options might result in
different link times as well.  PPC has short and long jumps, GOT, etc.
Sometimes compiles insert 'nops' to accommodate a long/short jump.
Sometimes the linker has to move things around to make room.  It does
seem plausible that there is a technical reason why it takes 20%
longer (but not 20x or 4x as long).  I wouldn't say it is completely
wasteful to investigate a 20% difference though.  It could be a bug.

Happy holidays...  I guess Santa is already come to some of you.  We
are still waiting in North America.

Fwiw,
Bill Pringlemeir.


--
For unsubscribe information see http://sourceware.org/lists.html#faq



More information about the crossgcc mailing list