[m-dev.] questions about grades

[Julien Fischer]

Hi,

On Wed, 24 Feb 2016, Zoltan Somogyi wrote:

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

Sorry, I meant that stream.m was not intended as a replacement for new
mercuryfile struct.  That said, the current stream.m was a replacement
for the old stream library from extras, which IIRC did date from around
the same time as mercuryfile struct.

> 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 :-(

I suspect C compilers don't expend a great deal of effort on that.  For
Mercury, it should be possible do better than we currently do in many
cases.

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

Fine by me.

Julien.