[m-users.] users Digest, Vol 107, Issue 14

[Volker Wysk]

Am Dienstag, dem 17.10.2023 um 21:24 +1100 schrieb Julien Fischer:
> On Tue, 17 Oct 2023, Volker Wysk wrote:
> 
> > Am Dienstag, dem 17.10.2023 um 16:41 +1100 schrieb Julien Fischer:
> > > On Mon, 16 Oct 2023, Volker Wysk wrote:
> > > 
> > > > This really surprises me. But they don't state if they used the low-level-C
> > > > (asm_fast) or the high-level-C backend. The former is faster.
> > > 
> > > Let me fix that for you: the former is sometimes faster for some
> > > programs on some systems for some versions of Mercury. For the Mercury
> > > compiler, for example, which of the two is faster has flipped around
> > > fairly regularly.
> > 
> > Hmmm. That surprises me. From what I've learned here in this list, the low-
> > level-C grade should be faster. It's a mixture of C and assembler, whereas
> > the high-level-C is just C.
> 
> Right, but in asm_fast grades most of that assembler is just the labels
> we use to avoid function calls. The code itself is predominently still
> C. Most of the reamining uses of assember are aimed at preventing GCC
> from "optimising" things in undesirable ways. A side effect of this is
> arrangement is that it tends to inhibit optimizations in the C compiler,
> whereas most C compiler optimsiations will work fine for high-level C
> code.
> 
> > When installing the RODT verson of the compiler, it always says that you get
> > a faster compiler, when doing both compilation passes.
> 
> Whether it recommends asm_fast.gc or hlc.gc depends on a number of
> things, for example which C compiler you using. There's not a
> significant difference between asm_fast.gc and hlc.gc (for the Mercury
> compiler at least), so we tend to recommend asm_fast.gc if it can
> be supported and hlc.gc otherwise.

Thanks for your arguments. It's more involved than I thought. I'll be more
careful with my assumptions from now on.

Cheers,
Volker