incremental linking?
Hal Daume III
hdaume@ISI.EDU
Sat, 25 Jan 2003 10:30:15 -0800 (PST)
Claus,
How did you get ghc to use gld when doing --make instead of standard
ld? I'm having the exact same problem you were and I'd love to make it
work faster.
Thanks in advance,
Hal
--
Hal Daume III
"Computer science is no more about computers | hdaume@isi.edu
than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume
On Sat, 30 Nov 2002, Claus Reinke wrote:
>
> 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
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>