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

[Julien Fischer]

On Wed, 20 Aug 2025 at 14:10, Peter Wang <novalazy at gmail.com> wrote:
>
> On Wed, 20 Aug 2025 13:37:14 +1000 Julien Fischer <jfischer at opturion.com> wrote:
> > On Wed, 20 Aug 2025 at 13:10, Peter Wang <novalazy at gmail.com> wrote:
> >
> > > I remembered something. On startup, LLDS .par grades will create a bunch
> > > of threads for Mercury engines (by default, one for each hardware thread),
> > > in preparation for running Mercury threads created with thread.spawn,
> > > or to execute parallel conjuctions. Those engine threads will often
> > > never be used because the program doesn't actually spawn non-native threads
> > > or contain parallel conjuctions.
> > >
> > > It might be possible to defer creating Mercury engine threads until they
> > > are actually needed, but it would need someone to make that effort.
> > > I don't think there is any interest now.
> > >
> > > So, as an easier option, it *would* make sense to introduce a .mt grade
> > > component for C grades that (unlike .par) supports multi-threading
> > > but not non-native threads or parallel conjuction.
> >
> > So with this proposal, in the grade asm_fast.mt.gc, spawn/3 would act
> > identically to
> > spawn_native/3?
>
> Yes, then asm_fast.mt.gc would behave like hlc.mt.gc in that regard.

In summary, the changes are then:

1. Do not allow concurrency in non .par (.mt) LLDS grades.  (Which brings
them into line with non .par hlc grades).

2. Introduce a new grade component ".mt". This will be supported by both the
MLDS C and LLDS grades and provide concurrency using native threads
(i.e. each Mercury thread is mapped onto a native thread.)

3. Restrict .par to the LLDS grades, where it will retain its current meaning
(i.e. parallel conjunction and Mercury threads multiplexed onto native threads
are supported.)

Julien.