guile prolog benchmark

guile prolog benchmark

[stefan]

Hi, I've come pretty far in writing a parser for prolog. It's a PEG
parser without packrat and interestingly it is done by doing a simple 
modding of a more standard match construct. The parser is custamizable
and it is pretty easy to add new user operators for prolog as you can in 
e.g. gnuprolog.

I did a new test with the famous n-queens example and here are the current 
performance statistics

gprolog WAM		350ms
gprolog COMPILED	100ms
moddeed guile           630ms

I find this quite reasonable and when we add naitive or JIT compilation it
should be fairly easy to take advantage of this as well for the modding I
have done.

Have fun
Stefan

Re: guile prolog benchmark

[Ludovic Courtès]

Hello,

Sounds fun.  Is the Prolog-on-Guile code available on-line?

Thanks,
Ludo’.

Re: guile prolog benchmark

[stefan]

On Monday 21 June 2010 11:58:18 pm Ludovic Courtès wrote:
> Hello,
> 
> Sounds fun.  Is the Prolog-on-Guile code available on-line?
> 
> Thanks,
> Ludo’.
> 

http://gitorious.org/guile-unify/

I think it's a good start. Also I will try to make a less rude
version of it. Until then you would not like to merge that code.
so it is best to keep it in "playground" for some time.

Regards
Stefan

Re: guile prolog benchmark

[Ludovic Courtès]

Hi Stefan,

stefan <stefan.tampe@spray.se> writes:

> http://gitorious.org/guile-unify/
>
> I think it's a good start. Also I will try to make a less rude
> version of it. Until then you would not like to merge that code.
> so it is best to keep it in "playground" for some time.

What justifies such a tight coupling with Guile core?

It would really help maintenance and review if this were an independent
package.  Only then should you consider optimizations that can only go
in Guile core, IMO.

Thanks,
Ludo’.

Re: guile prolog benchmark

[stefan]

On Tuesday 22 June 2010 01:49:59 pm Ludovic Courtès wrote:
> Hi Stefan,
> 
> stefan <stefan.tampe@spray.se> writes:
> > http://gitorious.org/guile-unify/
> >
> > I think it's a good start. Also I will try to make a less rude
> > version of it. Until then you would not like to merge that code.
> > so it is best to keep it in "playground" for some time.
> 
> What justifies such a tight coupling with Guile core?
> 
> It would really help maintenance and review if this were an independent
> package.  Only then should you consider optimizations that can only go
> in Guile core, IMO.
> 
> Thanks,
> Ludo’.
> 

I wanted to branch the repo into an orthogonal code at a point and move 
everything into the prolog directory under lang just as you want.

I think that this approach is a logical approach to combining a prolog vm
and a scheme vm though. why?

1. the vm has some registers like sp,ip that the prolog logic can take 
   advantage of.

2. doing it in scheme only lead to a waste of stack space. There is
   a "almost tail" call logic inside prolog.

3. prolog is very much like mathematical expressions. virtually every 
   operation will be a foreign call if the core is pushed into c which is not
   a stupid thing to want.

4. this aproach matches gprologs WAM in speed if I'm not misstaken, 
   but I think that by combining scheme and unification + backtracking means 
   that this approach have a selling edge.

5. A language component need to be performant, the competition is hard and 
also
   by pushing to the edge you will know that it is a good approach if it 
matches
   other mature implementations.

6. Although a tight coupling is difficult and cumbersome, other aspects 
   will line up very nicly and can nullify this difficulty.


Also I want the repo to be a case for anybody interested in how to mod a vm 
into beeing performant logic programming engine as well. I don't think you 
will get the same speed with java or c# whatever you do.

And last as a hacker I love to push things to the limits. I just wan't a 
have fun :-)

Regards
Stefan