[m-dev.] Improving compilation time?

Peter Wang novalazy at gmail.com
Wed Aug 17 11:36:58 AEST 2011

On 2011-08-17, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
> On Tue, Aug 16, 2011 at 02:27:25PM +0200, Magnus Holm wrote:
> > I'm a complete noob when it comes to both the language and the
> > implementation of Mercury, but one thing is clear: Mercury desperately
> > needs to improve the compilation-time in order to be more
> > attractive/useful to other developers. It's just a painful experience
> > to compile it from source.
> > 
> > So many decisions, so many hours to re-compile it:
> I've answered many of your questions specifically, however the general answer
> is that large projects take a long time to compile.  People rarely complain
> about having to compile Firefox, which probably takes longer to compile than
> Mercury.  They rarely complain about compiling large projects because they
> rarely have to because many projects make binary distributions and packages for
> various distributions available.  Which is what we should be doing, and
> something I'd like to have the time to do :-).
> I hope that the answers below can help in the short term and that one day I
> finish the Mercury packages for Debian and that they can help in the long-term.

Why can't we just tar up an installation every night?
Incompatible gcc versions?

> > - Should I first compile a Mercury with fewest possible grades, then
> > re-compile it with the useful grades?
> This is seldom necessary, and apart from that it can provide an optimization
> in only one case.
> If you have no Mercury compiler installed on a 64bit system then compiling the
> Mercury first in a single grade such as asm_fast.gc, installing that, cleaning
> the source tree and rebuilding will allow Mercury to make use of the extra tag
> bit that is available on 64bit platforms.  I think that most people don't
> bother with this extra step.

A tar.gz for 64-bit platforms would be very helpful.

> > I have no idea why it takes so long time to compile it, but there
> > certainly must be *something* we can do?
> This is answered in the FAQ, the main reason is because of the many grades that
> Mercury supports.
> On a multi-processor/multi-core system you should be able to ues the -j
> argument when you call make to run multiple jobs in parallel.

Plain 'make -j6 install' will NOT work as intended;
you must write 'make PARALLEL=-j6 install'
Conversely 'mmake PARALLEL=-j6 install' will NOT work as intended;
you must write 'mmake -j6 install'.

I have tried to rectify this broken situation, but it's not easy.
I think we should use all the cores on the system by default.
On Linux we can count the processors in /proc/cpuinfo or something.

> > - What about making it easier to install other grades after you've
> > installed Mercury? So you only install *one* first, but later add more
> > as you need them?
> I think that you might be able to 'trick' the build system into doing this.
> After saying 'make install' you might be able to install additional grades by
> issuing
> LIBGRADES=my_extra_grades mmake install_grades
> I haven't tried this so I don't know if it will work.

I do this:

    make install PARALLEL=-j6 LIBGRADES=

Then, as required:

    make install_grades PARALLEL=-j6 LIBGRADES='asm_fast.gc.debug hlc.gc'

For interest's sake, the first command took 3:45 min here, or about 10
mins CPU time.  The second command took about 13 min, or 31 min CPU time.
The build system is not as parallel in some places as it should be.

mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au

More information about the developers mailing list