[m-dev.] questions about grades

[Zoltan Somogyi]

On Wed, 24 Feb 2016 11:53:36 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> > 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.)

I don't understand. How could new mercuryfile struct (dating from 2000)
be intended to replace stream.m (dating from 2006)?

They both involve method calls, with mercuryfile these being hand-rolled
method calls in C, with stream.m automatically implemented method calls
in Mercury. Probably equally badly optimized :-(

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

Actually, new mercuryfile struct IS a grade component already,
though it is printed only in the link-check version of the grade,
not the user-visible version. I propose we keep it that way:
a grade component whose value is given by autoconfiguration,
doesn't affect any other grade component, and is user-invisible,
but linker-visible.

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

Thanks.

Zoltan.