Version française
Home     About     Download     Resources     Contact us    
Browse thread
Optimizing symbolic processing code
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Hugo Ferreira <hmf@i...>
Subject: Re: [Caml-list] Optimizing symbolic processing code

Kuba Ober wrote:
 > On Jan 16, 2009, at 11:19 AM, Hugo Ferreira wrote:
 >> Peter Ilberg wrote:
 >>> On Friday 16 January 2009 08:42:52 Hugo Ferreira wrote:
 >>>> I have implemented a simple Prolog like inference engine
 >>>> to be used in machine learning algorithms (ILP). My first
 >>>> basic test shows that inference is dismally slow (compared
 >>>> to a Prolog compiler).
 >>>> Consequently I am looking for information on optimizing the code.
 >>> For implementing a Prolog-like language, you might want to look at
 >>> this book on the Warren Abstract Machine:

 >> Ok, new of this document. But I think this demands too-much effort.
 > What you expect, basically, is for OCaml to magically translate your
 > likely cobbled-together, slowly performing interpreter into a bytecode
 > compiler and a VM.

See response to Andrej Bauer's e-mail please.

 > That ain't happening, and it's not OCaml's fault. Try compiling your
 > code in F# and see how fast it runs - I doubt you'll see an
 > improvement of more than an order of magnitude, unless you're really
 > unlucky to hit some OCaml's deficiencies.

This is exactly the type of information I am looking for.
What deficiencies does Ocaml have that may cause efficiency problems?
How should one go about looking for these problems?
What can one do to avoid or correct these problems?

 > I doubt that SWI Prolog would be
 > substantially (as in more than an order of magnitude linear constant)
 > slower
 > if it were ported to OCaml.

Let me make this clear: I am not attempting to port anything.
I want a resolution based system to be used in a learning algorithm.
Naturally I want performance on par with possibly less efficient
Prolog implementations like SWI (BTW, SWI is my preferred Prolog 
interpreter, so don't misread what I just said). In fact I don't
need much of Prolog's programming capabilities (otherwise I would
have used Prolog).

 > Writing a well-performing Prolog system is not an overnight task, at
 > least not without using some decent compiler/system building
 > libraries, which may not even exist.

Admittedly I am no expert in this or any other area for that matter.
Nevertheless this has not been "an overnight task". Again see
response to Andrej Bauer's e-mail please.

Hugo F.

 > Cheers, Kuba
 > _______________________________________________
 > Caml-list mailing list. Subscription management:
 > Archives:
 > Beginner's list:
 > Bug reports: