Re: any JIT compilers for Prolog?
- From: bart demoen <bmd@xxxxxxxxxxxxxx>
- Date: Fri, 06 Apr 2007 08:35:12 +0200
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
.
- References:
- Re: any JIT compilers for Prolog?
- From: rupertlssmith@xxxxxxxxxxxxxx
- Re: any JIT compilers for Prolog?
- From: Reuben Grinberg
- Re: any JIT compilers for Prolog?
- Prev by Date: Re: General Purpose parsing
- Next by Date: Re: Help with prolog derivative program
- Previous by thread: Re: any JIT compilers for Prolog?
- Next by thread: Help with prolog derivative program
- Index(es):
Relevant Pages
|