[m-dev.] questions about grades

[Zoltan Somogyi]

On Tue, 23 Feb 2016 14:21:04 +1100, Paul Bone <paul at bone.id.au> wrote:
> I think it's fine if this goes away.  As of 2015 MC havn't been doing any
> new projects in C (where MercuryFile is relevent), and if they recompile an
> old project with a new Mercury this is just one of the many things that may
> have changed.  I think the cost of maintaining it is higher than the risk of
> it breaking something and the cost of that breakage.

Actually, I haven't seen any "cost of maintaining it" until this email thread.

Thanks for all your replies; here are my proposals about what to do
about these grade components, and some new questions.

Zoltan.

-------------------------------------------------------------

I propose that we eliminate the .regparm grade component. I have three reasons.

The first is that it has no effect on modern machines. The condition for
it taking effect is currently this:

    #if defined(MR_USE_REGPARM) && defined(MR_HIGHLEVEL_CODE) && defined(__i386__)

so it works only on 32 but x86 machines, while modern x86 machines are actually
x86/64.

The second reason is that I tested what happens when this condition is relaxed,
and the last part of that test is replaced with

    ( defined(__i386__) || defined(__x86_64__) )

The result was a 3.2% SLOWDOWN, as shown by this summary of tools/speedtest
results:

    mercury_compile.1 average of 12 with ignore=1     14.35
    mercury_compile.2 average of 12 with ignore=1     14.81

The second line is with .regparm. This shows that .regparm has lost
its only intended purpose, which was getting a speedup.

The third reason is that "grep regparm doc/*" gives nothing, so noone
should be inconvenienced.

-------------------------------------------------------------

Neither .spf nor new mercuryfiles is hard to support, and they may have users,
so I will implement them in the grade library. If we want to delete them,
I think we should do so only after asking for objections on mercury-users.

BTW, I checked the overhead of enabling new mercuryfiles on tools/speedtest,
and it made no meaningful difference: the speed difference was very low down
in the noise. However, this does not say all that much, since the compiler
is FAR from I/O bound.

-------------------------------------------------------------

I looked into MR_PIC_REG, and it seems that this grade component hasn't had
any effect since 2007. Julien disabled it after we agreed that its cost
exceeded its benefits. The cost was incessant hassle with gcc bugs arising
from fact that in grades without picreg, we used to reserve THREE machine
registers, while with picreg, we reserved only TWO. Since that change,
we ALWAYS use just two. I don't see gcc developers getting any better at
respecting reserved registers, and the upside of using three registers
is so small anyway (in 2007, the log message says it was a 2.2% speedup), 
I don't see us changing that decision in the foreseeable future. Therefore
I propose that we just delete this grade component.

-------------------------------------------------------------

There were some things I forgot to ask about in the earlier email.

Was Ralph's history gc intended to be used in LLDS grades? Do we care?

I know we support thread segments in LLDS grades, and I know we don't
support trailing at all when targeting languages other than C.
Do we support trail segments when targeting high level C?

We allow a .par grade component to be added to a grade regardless of
what language we are targeting, but I have used only the LLDS .par grades
For those, the .par grade component means: multiple engines, reserve a register
for thread local data, and support for executing code in parallel, both
code that explicitly spawns off processes with thread.spawn, and code that
just uses parallel conjunctions. However, I vaguely remember that the .par
grade component means something different for the other targets: high level C,
Java, C# and Erlang, and not just in that they don't have a register to
reserve. Can the people who have implemented and/or used .par for these
targets tell me what the differences are, if there are any?