incremental linking?

[Claus Reinke]

It seems that Sun's ld was indeed the weak link. Switching to
Gnu's ld (*) brought the linking time down to just under 1 minute,
both on the machine that used to take 6 minutes and on the 
older one that used to take 20 minutes!

I don't know whether Sun's lds themselves are to blame or whether 
ghc/gcc generate output that suits Gnu's ld better than it does Sun's 
ld, but as long as ghc remains as it is, that doesn't really make a 
difference for our purposes. 

(slow) ld -V
ld: Software Generation Utilities - Solaris Link Editors: 5.8-1.276

(better) ld -V
ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.344

(winner) ld -V
GNU ld version 2.13.1
  Supported emulations:
   elf32_sparc
   elf64_sparc

We haven't done extensive testing yet, and earlier versions
of binutils (up to and including 2.13) are reported to have 
problems on Solaris, so don't throw away Sun's tools, but it 
looks as if our case is now closed (and incremental linking
isn't an issue anymore with these new link times!-)

Thanks for the helpful feedback, and Good Luck with the
other suspiciously slow systems!

Claus

(*) a little stumbling block here: gcc refers to PATH only *after* 
  perusing its preconfigured search paths. In our case, those included 
  /usr/ccs/bin, so we had to set GCC_EXEC_PREFIX instead (which 
  is used before the preconfigured paths). Check with:
  gcc -print-search-dirs

----- Original Message ----- 
From: "Claus Reinke" <claus.reinke@talk21.com>
To: <glasgow-haskell-users@haskell.org>
Sent: Friday, November 29, 2002 12:02 PM
Subject: Re: incremental linking?


> >I haven't been able to discern any pattern among those experiencing long
> >link times so far, except that -export-dynamic flag used by the dynamic
> >loader stuff seems to cause the linker to go off into space for a while.
> 
> We're still investigating here, but just a quick summary for our own
> (large) project:
> 
> - nfs doesn't seem to have too drastic effects, even in-memory disks
>   don't speed things up, time seems to be spend in computation
> - on our (admittedly overloaded and dated) main Sun Server, linking
>    could take some 20 minutes!
> - we've found a more modern (and not yet well-utilized;-) Sun server,
>   bringing the time down to 6 minutes..:-(
> 
> (from that, I thought linking might have to be expensive - how naive!-)
> 
> - the same program on my rather old 366Mhz PII notebook links in
>    about 1 minute (I didn't notice that at first, because overall compile
>    time is longer on my notebook - but that turns out to be caused by 
>    a single generated file, for which the assembler almost chokes; after
>    all, the notebook "only" has 192Mb memory, and the disk is crammed)
> - with the laptop as reference, I'd guess the problem is not ghc's fault
>    (unless it does things drastically different on cygwin vs solaris?)
> - on our Suns, gcc (and hence ghc) seem to use the native linker
> - sunsolve lists several linker patches to address problems like
>   "linker orders of magnitude slower than Gnu's". We seem to have
>   those patches, but we're checking again..
> 
> moral so far: if compilation of big projects takes a long time, it is worth
> checking where that time is spend. for the same project, on different
> systems, we've got different bottlenecks:
> 
> - large (generated) files [all systems]: assembler needs an awful lot
>   of space (not enough space->compile takes forever)
> - network disks: import chasing takes a lot of time
> - Suns (?): linking takes too long
> 
> will report again if we get better news..
> 
> Claus
> 
> PS. if we get linking times down to what seems possible, incremental
>        linking would no longer be urgent - we'll see..
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users