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

[Bijan Parsia]

On 17 Oct 2023, at 08:17, Volker Wysk <post at volker-wysk.de> 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.

To a first approximation, rules of thumb about ASM being faster than C being faster than Java are just that. 

> It's a mixture of C and assembler, whereas
> the high-level-C is just C.


A mixture of C and ASM might interfere with some optimisations a C compiler could otherwise do (just as it might accomplish some optimisations a C compiler cannot). 

The big opportunities for a Java HotSpot style JIT is in profile guided optimisations. Since the compiler has actual information on the pattern of use for any given run it can optimise for that pattern of use whereas a compiler without that pattern of use data cannot. (PGO is available in some cases for ahead of time compilers but you still need to make sure your profile load matches your actual load. JITs are more adaptive but of course that adaptation has costs.)

Also, though I imagine this is rarer these days, in certain circumstances compact byte code can beat ahead of time machine code if eg the bytecode, interpreter, and data all fit in cache when the binary code plus data do not. This would happen on the Newton it seems where NewtonScript byte code was much more cache friendly than C++ binaries. 

Cheers,
Bijan.