>> 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 <o...@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! _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe