[m-rev.] for post-commit review: fix mantis bug 361

[Paul Bone]

On Thu, Sep 18, 2014 at 04:52:23PM +1000, Julien Fischer wrote:
>
> On Thu, 18 Sep 2014, Paul Bone wrote:
>
>> The confusion between the different capabilities of the parallel grades (and
>> grades/backends in general) is something we're already working on to fix,
>> for example Peter's spawn_native contribution and your effort to standardize
>> the behaviour of floating point to string conversion between the different
>> grades.
>
> The floating point stuff is primarily down to differences between the
> target langauges and, for C, the fact that these things are not very
> strongly defined in the first place.
>
>> This is easier said than done but I think that the user shouldn'd have to
>> think about grades at all.  Typically their choices come down to just a few
>> options: Make it go fast, make debugging possible, or make profiling
>> possible.  And nowdays: make parallelism possible.
>
> That is precisely what Zoltan and I have said further back in this
> thread; however IMO the --add-grade-component options and the grade
> components themselves are not the right way to do this.
>
>> This is more of an ideal rather than a realistic goal (for Mercury in
>> it's current status).
>
> I think it's perfectly reasonable to (eventually) allow things like:
>
>    $ mmc --debug foo.m
>
> (Compile the program in the best available grade that can be used for
> debugging.)
>
>    $ mmc --debug --trailing foo.m
>
> (Compile the program in the best available grade that supports both
> debugging and trailing.)

I like this and I think it's a step in the right direction.  However it's
still a leaky abstraction, by an ideal goal I was thinking of a system with
many fewer grades (normal, debugging, profiling) and definitly not multiple
backends to the same target language.  I beleive this matches what users
want without adding unnecesary complexity, however it's extreamly
hypothetical and not something that realistically matches the Mercury
project in it's current form or with it's design goals (eg: not paying for a
feature like parallelism or trailing when your program doesn't use it).

> For the 'choose-the-best' options I think we need to make a distinction
> between --parallel and --multithreaded, for example:
>
>    $ mmc --high-level-code --parallel foo.m
>
> should be an error since the hlc grades don't support parallel
> conjunction.  The feature set pragmas already make this distinction
> between parallelism and concurrency.

That's a fair point and would avoid some confusion.

>>>>  And AFAIK it's rare that someone would want the stseg feature in a
>>>>  non-parallel build.
>>>
>>> The configure script currently enables stack segments by default for
>>> every for every low-level C grade except {asm_fast,reg,none}.gc and
>>> {asm_fast,reg,none}.gc.trseg, so it's hardly something that is
>>> restricted to the par grade.  (I am in favour of enabling stack segments
>>> by default for every low-level C grade.)
>>
>> I don't remember what the impact is but I don't think it's particularly
>> large so I'd be in favor of enabling it everywhere as well.
>
> That's odd, because IIRC you were the person who objected the last time
> I suggested it.
>

I honnestly don't remember.  I can see the benifit in it making things more
consistent but I don't remember the cost.


-- 
Paul Bone