[m-dev.] questions about grades

[Julien Fischer]

On Wed, 24 Feb 2016, Zoltan Somogyi wrote:

> On Wed, 24 Feb 2016 09:23:38 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
>>> Neither .spf nor new mercuryfiles is hard to support, and they may have users,
>>> so I will implement them in the grade library. If we want to delete them,
>>> I think we should do so only after asking for objections on mercury-users.
>>>
>>> BTW, I checked the overhead of enabling new mercuryfiles on tools/speedtest,
>>> and it made no meaningful difference: the speed difference was very low down
>>> in the noise. However, this does not say all that much, since the compiler
>>> is FAR from I/O bound.
>>
>> In that case, I propose that we either (1) enable new mercuryfiles by
>> default or (2) delete them entirely.  Either way, it's not a grade
>> component issue.
>
> To make a decision between those two, it would be nice to have some data
> on the performance impact on a program that IS I/O bound. Comparing
> the new mercuryfile struct with equivalent code using the stream interface.
> Does anyone know whether the stream-oriented library modules are a
> COMPLETE replacement for new mercuryfile?

In short, the former is not intended to be a replacment for the latter.
(And due to the fact that the compiler does a poor job of specialising
method calls, is probably slower anyway.)

It's a discussion for a separate thread anyway, as I think we agree
that it's not a grade component.

> Another question came to me, as I was writing the code to handle
> pregen grades in the grade library, which is: should pregen be a grade
> COMPONENT, or a complete grade? In other words: should pregen=yes
> determine the value of ALL the other grade components? It has always
> determined the value of tag location (low), number of tag bits (2),
> boxed vs unboxed floats (boxed) and therefore spf=no. However,
> it does not imply hlc, or .gc, or the absence of .ssdebug, or .par,
> or any other feature. There is no intrinsic reason why it should,
> but we use pregen for only one purpose, and for that purpose,
> we also DO use pregen together with hlc and .gc and without
> .ssdebug and .par etc. So in practice, I think it would be simpler
> if pregen was a complete grade in itself, and not a grade component.
>
> Any thought on this?

While the source distribution grade (currently hlc.gc.pregen) doesn't
change much, it does sometimes; notably we moved from low-level C to
high-level C a few years back.  While it is very unlikely we would
ever move back, in principle, building a source distribution with
the low-level C back-end should still work.

If there were ever another GC that could replace Bohem, we may want to
use that with the source distribution; the reason being that Beohm is
the source of *lots* of installation problems with Mercury.

On balance, I think I would prefer to keep pregen as a separate
component for now.

> Something else that came up: I am reasonably sure that mprof
> time profiling works only with the LLDS backend. However, I don't
> know whether mprof time and memory profiling are supposed to work
> when targeting high level C code. Does anyone know?

Both of them should work when targeting high-level C.  The only form
of profiling that doesn't work with it is .profdeep.

Julien.