[m-dev.] New release?

[Paul Bone]

On Thu, Oct 22, 2015 at 03:47:58PM +1100, Zoltan Somogyi wrote:
> 
> 
> On Thu, 22 Oct 2015 15:25:02 +1100, Paul Bone <paul at bone.id.au> wrote:
> > It looks like lines 8-9 are intended to implement a propagation step.  In
> > that case I would prefer to use a while loop (line 5), and propagate to
> > _any_ variable with a singleton set of "consistent values".
> > 
> > For example:
> > 
> >     take the set of such choices expressed on the command line
> >     if those choices are inconsistent, then
> >         report an error for each source of inconsistency
> >     else
> >  5      while there are unbound variables
> >             for each so-far unbound variable (any order):
> >                 compute the set of values of this solver variable that are
> >                     consistent with the values of the already-bound variables
> >                 if this set contains just one value
> >                     bind the variable to this value
> >                     break out of both loops (back to line 5)
> >             choose a variable (using "chosen order" as in Zoltan's line 5
> >             bind the variable to the value in the set that
> >                the user is most likely to implicitly want
> >             (in the table below, the default is the most preferred value)
> > 
> > This ensures that if the user specifies TAR=java, then CL=high will always
> > be set (via propagation) before a choice is made on a variable such as REG.
> > (REG=n will be propagated soon after.)
> 
> The two algorithms are equivalent. If a solver variable is set by the user
> (e.g. TAR=java), then no assignment can be consistent unless it includes
> all the settings implied by that (in this case, CL=high). Whether you record
> CL=high immediately or when the loop gets to looking at the possible values
> of CL does not matter.

What if the loop records REG=y before it gets to CL?  Or will the "choosen
order" always handle those situations?

> > > solver variable TAR:
> > >     TAR.c:  C
> > >     TAR.cs: C#                      (requires CL.hlc)
> > >     TAR.j:  Java                    (requires CL.hlc)
> > >     TAR.e:  Erlang                  (requires CL.hlc)
> > >     (default is TAR.c)
> > 
> > I think that "j" is the name of a language.  We may want to avoid confusion
> > and call this "java".
> 
> You are taking this too literally. This is a design description, not code.
> The reason why I kept the names short was to fit the constraints involving
> them into 80 columns. The actual names of the mutables will be more verbose,
> and in any case, no user will ever see them. They will see only the names
> of the options, and I was explicit about the fact that I am not yet proposing
> any names for THEM.

sorry.

> > even choose the order dynamically or add backtracking.
> 
> I don't think that will be needed. I certainly hope it won't, because
> implementing it in sh would be a bitch :-(

Yeah, I was worried the first time I read "solver variable".

> > If a user has not specified anything and a their platform supports REG but
> > not GOTO, and REG=y is selected first, then that would propagate CL=llc.
> > Unfortunately they'll end up with a grade like reg.gc when they could have
> > had a faster grade like hlc.gc.  This can probably be fixed by always
> > choosing CL before REG, GOTO or ASM.
> 
> Or by having the choice of CL (in the rare case when it isn't implied by other
> options) be influenced by the availability of registers, labels etc on the platform.

Yep.

> > I started work to rename this completely, after realising that support for
> > Mercury in the threadscope viewer would frequently be broken.
> 
> Rename what in what?

Rename --threadscope and the threadscope grade component to
--parallel-profiling.  Since it wouldn't be compatible with ThreadScope and
this name is more descriptive.


-- 
Paul Bone