[m-dev.] Mercury's "Time to Hello World"

[Julien Fischer]

Hi Michael,

I'll try to address some of the points you raise in your blog, or at least
explain why things are the way they are.

On Sun, Mar 24, 2013 at 8:31 PM, Michael Richter <ttmrichter at gmail.com> wrote:
> In which I talk about a bizarre metric and how it impacts one of my
> favourite programming languages.
>
> http://yfl.bahmanm.com/Members/ttmrichter/yfl-blog/mercury-time-to-hello-world
...

>     Further, the default configuration used when you do the traditional Unix
>     ./configure && make && sudo make install cycle builds a whole bunch
>     of "grades" that are completely unnecessary to the casual user.

What makes you think those grades are unnecessary?  The problem with just
installing a single grade sufficient to build hello world is this: immediately
after building hello world a lot of users try the following:

     $ mmc --debug hello

or
     $ mmc --decldebug hello

or
     $ mmc --parallel hello

or
     $ mmc --java hello

etc etc.
Guess what happens when it doesn't work because the required library library
grade is not there.  (Actually, don't guess, just have a look at the
mercury-users archives.)

The rationale for the default set of grades is this: it is the set of grades in
most of the useful features and tools that make up Mercury are available, i.e.

    -- support for trailing
    -- support for parallelism and threads
    -- support for debugging
    -- support for declarative debugging
    -- support for profiling
    -- support for memory profiling
    -- support for deep profiling
    -- optionally, support for the Java, C# and Erlang backends

In short, the aim is not to minimize THW, but to install a usable system in
which most of the major features will work.

IMO, there isn't really a good solution to this.  Installing just a single grade
isn't going to solve anything; you're just going to annoy a different
set of users.

>     I have had Mercury builds that took over two days (!) on an earlier machine I
>     owned (a single-core, 1.6GHz laptop) and even on my newer (dual-core, 2.2GHz
>     laptop) it still takes a minimum of 6 hours to do the "default" build.

Obviously YMMV, depending on machine speed, C compiler, linker, whether you are
using parallel builds or not.  On my machine (3.10Ghz i5) with a single core, a
complete default installation takes ~140m, with 4 cores (-j4) it takes 40m.

Six hours, let alone fifty, is bordering on excessive on modern machines, what
exactly are you using?  (We have come across excessively long compilations time
before, e.g. on Mac OS 10.5 and 10.6 with GCC 4.2, in that case it was due both
the C compiler and linker having performance bugs -- often such things can be
worked around, but of course such things need to be reported to us for that to
happen ...)

>    This person would have to know how to package the various grades
>    independently (or quasi-independently) of the core components and how to
>    install things from the various grades so that they won't clash

The grade dependent parts of the libraries are already separated.  Specifically,
for any given grade, the grade dependent files can be found in

     <install-prefix>/lib/mercury/ints/<grade>
     <install-prefix>/lib/mercury/lib/<grade>
     <install-prefix>/lib/mercury/modules/<grade>

where <grade> is the name of the grade in question.  Packaging the grades up
separately should be trivial.  (The only other thing that would need to be done
is to update the list of installed grades in the
<install-prefix>/lib/conf/Mercury.config when a grade is installed / removed.)

Cheers,
Julien.