[m-rev.] for review: granularity control

[Zoltan Somogyi]

On 03-Nov-2006, Peter Wang <wangp at students.csse.unimelb.edu.au> wrote:
> > +                Code = "SUCCESS_INDICATOR = " ++
> > +                    "MR_num_outstanding_contexts_and_sparks > " ++
> > +                    NumCPUsStr ++ ";",
> 
> This is specific to the low-level backend, but that's not checked in
> mercury_compile.m.  Also, I suggest calling a macro to make it easier to
> experiment with different heuristics.

I have replaced it with a macro, but is there a similar condition for high
level grades, and if so, what is it?

> > +                Args = [],
> > +                ExtraArgs = [],
> > +                MaybeRuntimeCond = no,
> > +                Features = [],
> > +                InstMapDeltaSrc = [],
> > +                goal_info_get_context(GoalInfo, Context),
> > +                some [!Attributes] (
> > +                    !:Attributes = default_attributes(lang_c),
> > +                    set_purity(purity_semipure, !Attributes),
> > +                    set_may_call_mercury(proc_will_not_call_mercury,
> > +                        !Attributes),
> > +                    set_terminates(proc_terminates, !Attributes),
> > +                    set_may_throw_exception(proc_will_not_throw_exception,
> > +                        !Attributes),
> > +                    set_may_call_mm_tabled(will_not_call_mm_tabled,
> > +                        !Attributes),
> > +                    set_may_modify_trail(proc_will_not_modify_trail,
> > +                        !Attributes),
> > +                    Attributes = !.Attributes
> > +                ),
> > +                generate_foreign_proc(ModuleName, ProcName, predicate,
> > +                    only_mode, detism_semi, purity_semipure, Attributes,
> > +                    Args, ExtraArgs, MaybeRuntimeCond, Code, Features,
> > +                    InstMapDeltaSrc, ModuleInfo, Context, Cond),
> 
> I can't see why the goal would need to be semipure.  It will read from
> the environment, but the result won't change due to the value it reads.
> Also, the values it will read will be affected by pure code, and will be
> dynamically changing due to the load so purity doesn't come into it.

Actually, I think that last part means it has to actually be *impure*.

I have followed your other suggestions. However, I found that while I can
run the par_fib and other tests just fine when compiling programs with lmc,
I get a core dump from every single test case, including the sequential ones,
during bootcheck. The core dump is on line 91 of mercury_thread.c, and is
due (according to gdb) to MR_thread_engine_base being *stored* at address 0
(not *containing* NULL, but having its *storage* put by the linker at 0).
Any ideas about what might be causing this? I am doing an asm_fast.gc.par
bootcheck of an unmodified workspace now to see whether it is related to my
change.

> On a related note, it would be useful to have some syntactic sugar for
> manual granularity control.  The following syntax is from &-Prolog, but
> we'd go for something else, I suspect.
> 
>     Cond => G1 & G2
> 
> would expand out to
> 
>     (Cond -> G1 & G2 ; G1, G2)
> 
> to save the programmer duplicating goals with different connectives.

I agree, but that is for the future.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------