[m-rev.] for post-commit review: document .par grades

[Julien Fischer]

On Tue, 19 Aug 2025 at 17:25, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:

>
> On Tue, 19 Aug 2025 16:15:58 +1000, Peter Wang <novalazy at gmail.com> wrote:
> > On Mon, 18 Aug 2025 13:05:36 +0200 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > > At the moment, it is not an *extra* grade component. It is a *rename*
> > > of the .par grade component to .mt, given that parallel conjunction
> > > does not work :-(
> >
> > Did something break parallel conjunction?
>
> Yes. It happened several years ago, but we don't know when or which commit,
> because as far as I know, the nightly tests have never included asm_fast.gc.par :-(
>
> > > I would be inclined to proceed as follows:
> > >
> > > - document the current .par grade as providing multithreading in C,
> > >   both LLDS and MLDS, with multithreading provided without .par
> > >   in C# and Java,
> > >
> >
> > Yes, this is what .par means.
> >
> > > - document that we plan to rename the .par grade modifier to .mt
> > >    after a transition period where both are valid,
> >
> > If someone wants multiple (native) threads, it's pretty much because
> > they want parallel execution.
>
> Or they may want concurrency, which is not the same thing.

These days you are going to have to go out of your way to *not* get
parallelism with your concurrency.

> I have no dog in this fight. You and Julien should agree on something,
> and when you do, tell me what it is, and I will document it.

So, if we don't want to introduce a new grade component, I suggest:

1. Disabling concurrency in non .par LLDS grades.  As discussed, except
for preventing philosophers from getting hungry, it's not useful in practice.
(spawn/3 and friends would throw an exception in all non .par C grades.)

2.  Keep .par as the component that enables concurrency in C grades,
noting that in LLDS C grades it also enables support for parallel
conjunctions (and further noting that parallel conjunctions are not supported
at all by the MLDS backend.)

Does that work for everyone?

> > .mt is a bit more direct, but .par was
> > fine as well. It's not worse than "asm_fast".
>
> That's because for anyone you doesn't know the history, pretty much
> no name is worse than asm_fast :-(
>
> The point of the rename would be to free up the .par name for
> parallel conjunctions. Of the two possible contenders for that name,
> multithreading is the one that has the better chance for a good
> alternate name.
>
> > > - document that eventually, we intend to use the .par modifier
> > >   for LLDS grades that support parallel conjunctions.
> >
> > If a grade has the prerequisites to support parallel conjunction,
> > and we've done the work to enable that support, I don't see why
> > it needs to be gated behind another grade modifier.
>
> Because enabling parallel conjunctions comes with overheads
> that we don't want to pay for programs that contain no parallel
> conjunctions.

Does enabling parallel conjunctions in the LLDS grades come with
additional overhead, beyond that which is required to support concurrency?
(Certainly, code that contains parallel conjunctions incurs some overheads,
which you hopefully make back from the parallelisation, but I didn't think
the overhead from parallel conjunction were of the distributed fat type
we incur for things like trailing or debugging.)

Julien.