Re: any JIT compilers for Prolog?



On Fri, 06 Apr 2007 00:22:54 -0500, Reuben Grinberg wrote:

I'm pretty sure Sicstus, the commercial prolog implementation is JIT.

It depends on what one means exactly with JIT - I am not interested in
picking a fight about that BTW.

BIM-Prolog had the following schema in 1985:
a standalone compiler compiles Prolog source in file.pl
to WAM bytecode and saves it in a file.wic
on consulting a Prolog program from file.pl, the file.wic
is loaded and during the loading, the static preds
in it were further compiled to native code (on Sparc
and Intel - on other platforms, static preds would
remain bytecode interpreted)

Basically SICStus followed the same schema, except that the defaults
is not to save the bytecode in a file, but to compile to bytecode
on loading a file. SICStus has given up recently on compiling further
to native code.

I wouldn't name the above JIT: it is just a staged compiler whose last
fase happens late. It doesn't do hot-spot like stuf, neither does it
improve generated code through runtime characteristics.
But if you want to name it JIT, no problem :-)

Yap generates indexing code on demand, i.e. it waits until a call shows
an instantiation pattern that is worth generating indexing code for.
That has more JIT flaour to it.
Paul Tarau's moving code from interpreted to compiled based on some
frequency heuristic has JIT flavour. But be careful: in BinProlog,
compiled doesn't mean compiled to native code [unless things have changed
drastically since I looked last]

One can wonder why real compilation (to native code or to C) isn't more
popular with Prolog implementors. It is really difficult to beat a fast
bytecode emulator (like Yap, hProlog, B-Prolog) with native code or C
generation unless one uses strong program analysis - that the latter
is possible was proven by CIAO people, and longer ago by Peter Van Roy
with his Aquarius. Mercury proves essentially the same point. Without
analysis, the gains (if any) are too small - probably one of the reasons
why SICStus gave up on native code.

Yesterday, I hand coded the tak benchmark in C - but doing all the things
Prolog requires: checking for free/wrong type/overflow ... - hooked this
code up to my emulator and I got a 30% speedup. Not worth the effort.
Moreover, many applications (not the usual benchmarks of course) use
builtin preds a lot; they are written in C already. One would not gain in
that portion of the program. I think SICStus used to gain a factor of 2 on
non-benchmarky programs.

Cheers

Bart Demoen


.



Relevant Pages

  • Re: Why does activex control run 3x+ faster in vb5 than .net?
    ... Looks like a good interpreter works almost as fast as a bad compiler. ... Native code and MSIL compiled code is not the same thing - Native code can be more or less be directly executed on the CPU while MSIL requires the extra step of gothrough the JIT. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Why does activex control run 3x+ faster in vb5 than .net?
    ... is compiled before it is run for the first time and with JIT ... So the only performance hit JIT is giving, ... Regardless of what you want to say - MSIL is NOT native code. ... There is only a just in time COMPILER that compiles the ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Why MC++ is faster then C# ?
    ... If you have specific scenarios that you think are unknown to the JIT team, ... Rememver that the MC++ compiler is very mature, ... performance out of a JIT than "pre"-compiled native code). ... > Pierwszy łyk z pucharu nauk przyrodniczych czyni ateistą, ...
    (microsoft.public.dotnet.framework.performance)
  • Re: .NET 2.0 to be launched on Nov 8
    ... Native Delphi has no JIT to generate the ... In .NET, the JIT instantiates them for you, but who does this for native code? ... code generations for the same instantiation. ... of the compiler writers control. ...
    (borland.public.delphi.non-technical)
  • misc: lang effort, performance
    ... I added a define that allowed me to enable/disable ref counting to see what ... a c implementation of the algo takes about 110ms (generic compiler options). ... I had started to consider the possibility of jit compilation. ... of course, thinking of it, some optimizations (those which I had originally ...
    (comp.lang.misc)