[Haskell-cafe] faster compiling for ghc
Evan Laforge
qdunkan at gmail.com
Wed Nov 11 20:02:17 EST 2009
Recently the "go" language was announced at golang.org. There's not a
lot in there to make a haskeller envious, except one real big one:
compilation speed. The go compiler is wonderfully speedy.
Anyone have any tips for speeding up ghc? Not using -O2 helps a lot.
I spend a lot of time linking (ghc api drags in huge amounts of ghc
code) and I'm hoping the new dynamic linking stuff will speed that up.
I suppose it should be possible to run the whole thing under the
bytecode compiler, and this works fine for rerunning tests, I can just
stay in ghci, make changes, :r and rerun, but it runs into trouble as
soon as code wants to link in foreign C. I also recently discovered
-fobject-code, which indeed starts compiling right away, cutting out
the ghc startup overhead. However, it doesn't appear to help with the
final link, so I wind up having to reinvoke ghc anyway.
According to Rob Pike, the main reason for 6g's speed is that in a
dependency tree where A depends on B depends on C, the interface for B
will pull up all the info needed from C. So compiling A only needs to
look at B. Would it help ghc at all if it did the same with hi files?
I've heard that ghc does more cross module inlining than your typical
imperative language, but with optimization off maybe we can ignore all
that?
I've seen various bits of noise about supporting parallel builds with
--make and it seems to involve making the whole compiler re-entrant
which is non-trivial. Would it be simpler to parallelize pure
portions of the compilation, say with parallel strategies? Or just
start one ghc per core and have a locking scheme so they don't step on
each others files?
More information about the Haskell-Cafe
mailing list