[m-dev.] Improving compilation time?

[Paul Bone]

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.


> - What grades do I need?

That depends what you want to do, you should start with a low level C grade
such as asm_fast.gc and add other features if you think you will need them, for
example profiling and debugging:  A programmer who wants to program in Mercury
probably wants profiling and debugging support.  Someone who just wants to run
another person's Mercury program wont need these features.

> - What's do I gain by re-compiling Mercury with a current installation?

I don't understand, compared to what?

> - 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.


> 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.

> - Is there anything you could pre-compile and ship with the tar.gz?

We already do this a little bit, simply to allow users to bootstrap (install
Mercury on a system where Mercury is not yet installed).  We could be more
aggressive about this, however it is not trivial to implement and can make the
Mercury distribution much larger.

> - 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/developers/attachments/20110817/7fe6a437/attachment.sig>