[Haskell-cafe] faster compiling for ghc

[Evan Laforge]

>> Running GHC in parallel with --make would be nice, but I find on
>> Windows that the link time is the bottleneck for most projects.
>
> Yes, when GHC calls GNU ld, it can be very costly.  In my experience, on a

This is also my experience.  GNU ld is old and slow.  I believe its
generality also hurts it, there is a much faster linker called gold,
but it's ELF-only.

The reference to incremental linking was interesting, but AFAIK gnu
and apple ld don't support that.

> linux virtual host I had to build my own GHC to disable split-obj because
> having it enabled caused ld to use about 1GB of memory.  This is insane for
> a virtual host.  I tried to solve it by adding swap that meant linking a
> trivial Setup.hs took about an hour.

Oh, this is interesting.  I recently stumbled across split-obj, and I
gathered it's a special ghc hack to reduce binary size by putting
functions in their own obj files (I guess ld is not smart enough to
only link used code?).  If it slows down links, would it be worthwhile
to disable split-obj for normal builds, and turn it on with -O2 for a
production build?

> In conclusion, improving GNU ld could be a huge win for GHC, at least on
> linux.  Does GHC on windows use GNU ld?

Improving GNU ld would be a huge win in a lot of places, and the fact
that no one has done it (excepting gold of course) goes to show it's a
lot easier said than done!



On Thu, Nov 12, 2009 at 4:58 PM, Richard O'Keefe <ok at cs.otago.ac.nz> wrote:
>
> On Nov 12, 2009, at 2:02 PM, Evan Laforge wrote:
>
>> Recently the "go" language was announced at golang.org.
>
> It looks a lot like Limbo; does it have Limbo's dynamic loading?

Nope, I don't think it's that similar to limbo actually, though it
does have channels.  It reminds me of haskell in some places, for
example no implicit conversions, RTS multiplexed lightweight threads,
and interfaces which are vaguely similar to typeclasses.  The channels
are a subset of TChans, its select {} is like a non-nesting orElse
restricted to reading from channels.

>> According to Rob Pike, the main reason for 6g's speed
>
> It's clear that 6g doesn't do as much optimisation as gccgo.
> It probably doesn't do as much optimisation as GHC.
> And it certainly doesn't have any kind of generics, let along
> type-level programming.
> I'd say the semantic distance between 'go' and x86 is quite a
> bit less than that between Haskell and x86.  No laziness!

Indeed, the language is closer to the hardware and the type system is
simpler.  However, ghc can also be run without optimization.  I think
the main issue is that the designers had compilation speed as a
feature from the beginning, and implemented some neat tricks to that
end, which is why I mentioned how it pulls dependencies up to minimize
file reading.

Of course it could be that ghc already accomplishes the same end with
--make by just keeping the interfaces in memory.  Or file reading time
is dwarfed by compiler cogitation.  Of course a research language
needs a flexible evolving compiler, maybe that's incompatible with a
fast one.  But fast builds are such a pleasure!