[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inclusion of guile-log II

From: Ludovic Courtès
Subject: Re: Inclusion of guile-log II
Date: Mon, 09 Apr 2012 22:15:05 +0200
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.93 (gnu/linux)

Hi Stefan,

Stefan Israelsson Tampe <address@hidden> skribis:

> On Wed, Apr 4, 2012 at 11:52 PM, Ludovic Courtès <address@hidden> wrote:
>> Hi Stefan,
>> Stefan Israelsson Tampe <address@hidden> skribis:
>> > If you want independence use kanren. For guile this approach is 10x
>> faster
>> > then kanren
>> > and 10x slower that a compiled prolog. Previously I thought that kanren
>> has
>> > a more functional
>> > fundament and can express amazing things. But i'm now inclined that
>> > guile-log has a feature
>> > that are very cool and I will try to explain this feature for the fun of
>> it.
>> Any idea why there’s such a performance difference?
> Yes the lookup cost can be substancially higher (in guile-log that's just a
> one or two dereferenses) but on kanren you need to search an alist of all
> bindings,

That’s no excuse: Kanren could use a vhash or similar, as you noted.  ;-)

> the number of lambdas is more for each operations and, maybe not that
> important but the allocations in guile-log is from a stack, but kanren
> uses a heap. the unify function in guile-log is in C while the same
> function is kanren is in scheme. And lastly guile-log is a heavy
> macrology in order to support cut's but kanren uses no cut and can
> stay functional, but this means that kanren features more lambda
> constructions and i'm uncertain if peval can counteract this.

Hmm, OK.


> Well if you want to translate prolog programs to scheme guile-log is
> actually a better fit

But I’m not sure whether getting Prolog programs translated is a worthy
cause.  :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]