George Russell wrote:
[snip]
> It won't be so hard to
> speed up GHC later if that becomes important.
Since this has been disputed, here are three ways I believe you could speed up
GHC without rewriting the whole of it. I would be surprised if you didn't get
at least twice the speed, and you could probably get a lot more. The
suggestions are in increasing order of difficulty. I don't say that all
of them will produce dramatic improvements; you would of course have to
experiment.
(1) (I've suggested this before.) Make GHC access interface files more
efficiently. If you do top and truss (on a Sun system) you will find
that GHC has to read in a huge number of interface files, mainly from
the prelude but also from other places, to get going. This is all done
just using fopen in a single thread so the whole of GHC is grounded while
the disk spins and (if you are using NFS like me) you wait for the network.
A quick fix would be to use a Zip archive or something similar; there are
not many parts of the source to change. Then you would only have to open
one file for the whole of the prelude and believe me that would make a
difference.
(2) Stop using Make, instead steal SML/NJ's clothes and have your own
compilation manager. This solves problem (1) nicely and also means you
don't have to read in anything else over and over again. (Like hsc
itself.) For programs which consist of lots of small modules, as they
should, this would also save lots of time. Actually I think this would
also provide much better handling of instance declarations. At the moment
instance declarations are only picked up from files which GHC "knows about"
via a transitive chain of imports. This has two user-unfriendly consequences;
(a) it means that when a .hi file changes, every module which transitively
imports (rather than just directly imports) has to be recompiled; (b)
it is counter-intuitive. It would be better if all instance declarations
in the compilation manager files were automatically known about.
I can testify that SML/NJ's compilation manager really works very well
and you don't miss the ability to set different compiler options for
different files.
Note that neither of these two suggestions actually do anything for
GHC's cpu time. If I run top when GHC is running I rarely find it
is using up more than 50% of the available CPU time; most of the time it
is waiting on IO. However:
(3) Stop using GCC-C as a backend. Instead make the GHC backend a new
frontend to GCC. See
http://www13.informatik.tu-muenchen.de/forschung/papers/eigene/piz_gic.ps
for some explanation and arguments for this approach.
Of course there are other obvious approaches. I'm sure it's unnecessary
to re-code GHC in C to get C-like performance. Surely it would
be better to optimise key sections of GHC by the normal tricks of
unboxing things and specialising.
I'm not suggesting that the GHC implementors actually do any of these
suggestions now (though I suppose they could put them on the wish list).
I'm much more concerned about getting GHC and Hugs talking to each other.
