An Haskell compilation server

Sebastien Carlier sebc@posse42.net
Wed, 17 Jan 2001 10:48:20 +0100


John Meacham wrote:
> the benefits may not be as great as you suppose, modern operating
> systems keep a buffer cache which contains all recently used data in
> memory including executables, if your machine is not memory limited
> (such that the OS would have to throw away your ghc pages to make room
> for something else) then probably most of ghc's pages will already be
> resident in RAM for subsequent runs.

Even if the executable file is cached, there is still dynamic linking
to be done. Are pages of the executable memory mapped, or does the
binary file format get in the way and force the code segment to be
copied ? (this is architecture dependent, it would be interesting to
find out for the most common ones)

Even if the loading time is only slightly shorter, I think more
interesting speed-ups can be achieved by removing any work which
is duplicated by the compiler at each run. This probably includes
parsing .hi files. Where does the compiler spend most of its time ?

> if you wish to distribute the make over several machines that can be
> done easily by using 'ssh' or 'rsh' to start jobs on remote machines
> and share the results via nfs or smb or some other remote filesystem.

This would be very difficult without analysing the dependencies
between modules, I think the compilation has to be globally coordinated.
Also, you probably want to use only compilers for the sate architecture,
although you might have compilation servers for several. They should
register themselves to a central coordination server, which could also
balance the workload between servers.
I do not think this would be efficiently done with shell scripts.

> there are also certain versions of make such as 'pmake' which
> specialize in distributing building across clusters of machines...
> modifying 'hmake' to distribute the builds automagically might be
> an interesting and useful project though.

This would indeed be nice for universities and large sites.
And rebuilding ghc would be a breeze :)

> -- 
> --------------------------------------------------------------
> John Meacham   http://www.ugcs.caltech.edu/~john/
> California Institute of Technology, Alum.  john@foo.net
> --------------------------------------------------------------