Release of ECLiPSe 6.0
Kish Shen
version of the open-source Constraint Logic Programming platform.
It is now ready for download in source and binary forms, from our
Sourceforge download page:
http://sourceforge.net/project/showfiles.php?group_id=177708
and also from the ECLiPSe-CLP website:
http://www.eclipse-clp.org/download.html
Note that the ECLiPSe-CLP website always has the latest successful
build of ECLiPSe, but usually fewer binary distributions.
The major change in this version is the replacement of the old ECLiPSe
compiler by a new one written entirely in ECLiPSe itself. This has
enabled us to address a few long-standing problems with the old
compiler, to implement several performance improvements to the runtime
system, and to provide new debugging features like source-linked
tracing and setting of breakpoints. We also hope that this change
makes it possible for researchers to experiment with ECLiPSe more
extensively.
There have been extensive changes internally associated with the new
compiler, but we have tried to minimise the incompatibilities and
changes that will affect the general user. We have also tested the
system extensively, but with such a fundamental change, it is possible
that something was missed. Please try out your existing applications
with the new compiler, and let us know of any problems, feedback or
comments.
As usual, there are various further enhancements to kernel, built-ins
and existing libraries, as well as several new user-contributed
libraries. See the release notes
http://eclipse-clp.wiki.sourceforge.net/ECLiPSe+6.0+Release+Notes
for more details of these changes.
ECLiPSe is a Constraint Logic Programming platform, with a programming
language that is an extension of standard Prolog, and includes a host
of libraries to support constraint solving and program development.
It has been in development for many years, and was open-sourced in
September 2006 under a Mozilla-style Public Licence, allowing
unrestricted use (http://www.eclipse-clp.org/licence/). Development is
being sponsored by Cisco Systems, the owner of the original code base.
Kish Shen and Joachim Schimpf
neng...@gmail.com
> We are please to announce the release of ECLiPSe 6.0, a major new
> version of the open-source Constraint Logic Programming platform.
> It is now ready for download in source and binary forms, from our
> Sourceforge download page:
>
> http://sourceforge.net/project/showfiles.php?group_id=177708
Hi Kish,
I have updated the performance results of Eclipse at:
http://probp.com/performance.htm
The Prolog engine of version 6.0 is slightly faster than that of 5.1
(the average ratio w.r.t. B-Prolog is 2.48 compared with 2.85 before),
but the CLP(FD) system is slightly slower.
Cheers,
Neng-Fa
Wit Jakuczun
> but the CLP(FD) system is slightly slower.
>
Not sligthly but significantly! It stops me
from using a new version of ECLiPSe in
production system.
There are however few nice features. The one
I most like is source-based debugger.
Best regards,
Wit Jakuczun
Markus Triska
> Not sligthly but significantly!
Yes - for example, this now takes very long with 6.0_42 on OSX 10.4:
:- lib(fd).
:- X #> 10000000000000000.
bart demoen
> Not sligthly but significantly! It stops me from using a new version of
> ECLiPSe in production system.
Please don't take too quickly a decision on stopping the use of ECLiPSE:
it is not something in the implementation of ECLiPSe that causes the
slowdown, but apparently, a new version of gcc produces very inefficient
code for the C-code that hasn't changed (*). ECLiPSe people are looking
into the problem. Using a non 4.<something> version of gcc gives back the
old speed (as far as I know) and the fact that Neng-Fa Zhou reports only
a slight slowdown, might be because he is not using gcc (Neng-Fa, can you
tell us what you used - or did you download binaries [on windows ?] - in
which case we would like to know what ECLiPSe is compiled with for the
binaries [on windows])
I really expect the significant slowdown to be a temporary problem.
Cheers
Bart Demoen
(*) such a thing happened a few years ago with some 3.<something>
version; it currently looks as if an old problem raises its head in
4.<something>
Kish Shen
I was hoping to comment when I have more data, but given the other
postings, I guess I should say something now.
As Bart says, gcc 4.3.2 produces a slower ECLiPSe executable when
compare to gcc 3, at least for 32bit x85 Linux, which is where I made
the comparison. We don't distribute this binary.
Wit is not using an ECLiPSe compiled by gcc 4; he is using the binary
distribution of the Windows version of ECLiPSe, where both 5.10 and 6.0
(the two ECLiPSe versions being compared) are generated by the same gcc
compiler. [we cross-compile on Linux using a `mingw32' version of gcc,
to answer Bart's question]
I have been exchanging e-mails with Wit about this problem. His problem
is because the garbage collection time is much higher in the ECLiPSe 6.0
run -- 100 times more. About 2/3 of the execution time of ECLiPSe 6.0 in
his execution is spent in garbage collecion. If you discount the
garbage collection times, then 6.0 does run faster, although I don't
think it really make sense to report this time.
In the tests I have done previosuly, there is one other program which
had much higher gc times in 6.0, although it is nowhere near as big as
in Wit's case. I have had no time yet to investigate the issue further
than this.
Cheers,
Kish Shen
Kish Shen
lib(fd) is essentially an obselete library -- we recommend that people
use lib(ic) for finite domain solving. [the documentation for lib(fd) is
in the "Obsolete libraries manual", our way of hinting that you should
not use it :-) ]
The problem you mention has nothing to do with version 6.0 -- you have
the same problem with other versions of ECLiPSe -- I have just checked
with ECLiPSe 5.10 (on my Windows XP laptop).
The problem here is that lib(fd) is not designed to handle numbers as
large as the one you are using. It is more or less limited to
-10000000..10000000. [lib(ic) does not have this limit].
Cheers,
Kish
Markus Triska
> the same problem with other versions of ECLiPSe -- I have just checked
> with ECLiPSe 5.10 (on my Windows XP laptop).
I compared with 5.10_85 on OSX 10.4, which did not have this problem:
[eclipse 2]: X #> 10000000000000000.
syntax error: numeric constant out of range
| X #> 10000000000000000
> [lib(ic) does not have this limit].
Thanks.
Kish Shen
bignum allows ECLiPSe to use integers of essentially unlimited size.
This requires GNU GMP library when ECLiPSe is compiled. If you do not
have bignum support, then ECLiPSe will return the error you see when
your integer is not representable by your word length (32 bit in your
case). It would seem that the 5.10#85 you are using is compiled without
GMP, but your 6.0#42 is. If you run a 5.10 with bignum support, you
should also have the same problem of the predicate hanging.
lib(fd) is partly implemented in C, and I strongly doubt that this can
cope with bignums, even if ECLiPSe can. This is probably why you have
the problem with fd when you use a bugnum.
Cheers,
Kish
Wit Jakuczun
> On Thu, 02 Oct 2008 08:57:07 -0700, Wit Jakuczun wrote:
> > Not sligthly but significantly! It stops me from using a new version of
> > ECLiPSe in production system.
>
> Please don't take too quickly a decision on stopping the use of ECLiPSE:
according
to the well known rule, I am not going to change it. Maybe in a
future.
Nevertheless, the speed is not a main reason for using this or that
Prolog.
The most important for me is the library of global constraints and
ability to create new one.
> ECLiPSe people are looking
> into the problem. Using a non 4.<something> version of gcc gives back the
> old speed (as far as I know) and the fact that Neng-Fa Zhou reports only
> a slight slowdown, might be because he is not using gcc (Neng-Fa, can you
> tell us what you used - or did you download binaries [on windows ?] - in
> which case we would like to know what ECLiPSe is compiled with for the
> binaries [on windows])
>
I have talked to Kish Shen. It seems to be a gc problem mainly. But
the
case needs more checking for which I do not have time now.
Best regards,
Wit Jakuczun
Neng-Fa Zhou
executable was created by MVC++, but clearly I was wrong.
I have just done a comparison of the executables of B-Prolog generated by
MVC++ (version 6.0) and MinG GCC (version 3.4.5). It turned out that the
executable generated by MVC++ is 33% faster than that generated by MinG. So
it may worth it to purchase MVC++ to get some speedups. I'll compare MVC++
version 2005 and version 6.0 to see if there is any difference.
One thing that puzzles me is that while the Prolog engine of ECLiPSe 6.0
demonstrates some speedup (16% by my comparison) the CLP(FD) solver slows
down by about 20% although the same gcc compiler was used. I haven't tried
the ic module, but I heard that ic is not faster than fd.
Cheers,
Neng-Fa
Jan Wielemaker
> I installed the binaries of version ECLiPSe 6.0 for Windows. I thought the
> executable was created by MVC++, but clearly I was wrong.
>
> I have just done a comparison of the executables of B-Prolog generated by
> MVC++ (version 6.0) and MinG GCC (version 3.4.5). It turned out that the
> executable generated by MVC++ is 33% faster than that generated by MinG. So
> it may worth it to purchase MVC++ to get some speedups. I'll compare MVC++
> version 2005 and version 6.0 to see if there is any difference.
Your MinGW appears a bit old. A quick scans shows at least GCC 4.2 is
already supported in MinGW. I don't have the exact figures, but 4.2
generally produces significantly faster code than 3.5. For SWI-Prolog,
GCC 4.2 produces code that is about 10% faster than MSVC6. Partly that
is due to the use of a gcc language extension (fetch addresses of
labels). Most likely another issue is the fact that I do the
optimization using the Linux toolchain. I suspect the same applies to
ECLiPSe.
In other words, comparing performance using a single platform/compiler
can easily lead to differences of 10-30%.
Cheers --- Jan
P.s. Could you update to SWI-Prolog 5.7.1 and its clp(fd)? Curious how
well Markus' clp(fd) performs in these tests :-)
Neng-Fa Zhou
"Jan Wielemaker" <j...@nospam.ct.xs4all.nl> wrote in message
news:slrngen8j...@ct.lan...
> P.s. Could you update to SWI-Prolog 5.7.1 and its clp(fd)? Curious how
> well Markus' clp(fd) performs in these tests :-)
I have managed to have the benchmarks run (by peeking into the source code
in clp/clpfd.pl:-) except for bridge.pl. How to describe objective functions
for optimization problems in SWI? For example, how to write the B-Prolog
predicate minof(Goal,Exp)?
Cheers,
Neng-Fa
neng...@gmail.com
>
> news:slrngen8j...@ct.lan...
>
> > P.s. Could you update to SWI-Prolog 5.7.1 and its clp(fd)? Curious how
> > well Markus' clp(fd) performs in these tests :-)
I have updated the results at:
http://probp.com/performance.htm
The good news is that SWI-Prolog is not the slowest Prolog system any
more:-), and the bad news is that the clp(FD) system is over 100 times
slower than B-Prolog. Let me know when the clp(FD) system is improved
so I'll update the resuls in a timely way.
Cheers,
Neng-Fa
bart demoen
>
> I have updated the results at:
>
> http://probp.com/performance.htm
>
> The good news is that SWI-Prolog is not the slowest Prolog system any
> more:-), and the bad news is that the clp(FD) system is over 100 times
> slower than B-Prolog. Let me know when the clp(FD) system is improved so
> I'll update the resuls in a timely way.
It looks to me that you have screwed up the timings once more: you should
not load files into GNU-Prolog with [file] or consult; instead, you
should properly compile them (*) and then execute the executable. I just
checked one program - tak - and indeed, GNU-Prolog is a bit slower than
SWI when you use [...] or consult, but it becomes close to 5 times faster
if you follow the proper procedure.
(*) you use cl(file) for B-Prolog instead of [file], don't you ?
If you don't, B-Prolog is about a factor 3 SLOWER than even SWI !
Please report proper timings !
Cheers
Bart Demoen
ps. not that I disagree fundamentally with your conclusion on clp(fd);
still, take into account that in SWI, it is written in plain SWI Prolog,
without any support from the engine except for the attributed vars
Jan Wielemaker
> On Wed, 08 Oct 2008 12:23:22 -0700, neng.zhou wrote:
>
>>
>> I have updated the results at:
>>
>> http://probp.com/performance.htm
>>
>> The good news is that SWI-Prolog is not the slowest Prolog system any
>> more:-), and the bad news is that the clp(FD) system is over 100 times
>> slower than B-Prolog. Let me know when the clp(FD) system is improved so
>> I'll update the resuls in a timely way.
>
> It looks to me that you have screwed up the timings once more: you should
> not load files into GNU-Prolog with [file] or consult; instead, you
> should properly compile them (*) and then execute the executable. I just
> checked one program - tak - and indeed, GNU-Prolog is a bit slower than
> SWI when you use [...] or consult, but it becomes close to 5 times faster
> if you follow the proper procedure.
>
> (*) you use cl(file) for B-Prolog instead of [file], don't you ?
> If you don't, B-Prolog is about a factor 3 SLOWER than even SWI !
>
> Please report proper timings !
Yip. For SWI, use "pl -O" or ?- set_prolog_flag(optimise, true). This
could make a significant change for some of the tests doing a lot of
arithmetic.
SWI-Prolog is compiled using MVC 6.0 in MS-Windows (32-bit version;
the 64-bit version is compiled with MVC 2005). GCC produces better
code for it and I'll probably switch to MinGW once the 64 bit suite
is stable enough and I have some time ...
Thanks --- Jan
Neng-Fa Zhou
"bart demoen" <b...@cs.kuleuven.be> wrote in message
news:gcj5jl$hrh$1...@ikaria.belnet.be...
> On Wed, 08 Oct 2008 12:23:22 -0700, neng.zhou wrote:
>
> It looks to me that you have screwed up the timings once more: you should
> not load files into GNU-Prolog with [file] or consult; instead, you
> should properly compile them (*) and then execute the executable. I just
> checked one program - tak - and indeed, GNU-Prolog is a bit slower than
> SWI when you use [...] or consult, but it becomes close to 5 times faster
> if you follow the proper procedure.
Yes, I am so good at screwing up things:-), but for this comparison I did
try to use the compile option in every compared system that gives the best
performance. For SICStus, I used compile(file) instead of [file], and for
Eclipse I used the nodbgcomp mode. For GNU-Prolog, I didn't compare the
native code compiler ([file] in GNU-Prolog generates byte code unlike in
B-Prolog and SICStus-Prolog where [file] retains the source code) because
it does not support separate compilation which is needed to run my
benchmarking script. As for SWI-Prolog, I was not aware there was an
optimization option. I'll redo the benchmarking and update the results on
Monday.
Cheers,
Neng-Fa
Jan Wielemaker
No worries. Bart seems expert, but when I tried to run a program on
different systems it was surely not obvious how to run it `optimally'.
On the other hand, Prolog is not unique in this, so we need to be only a
little bit ashamed here :-)
Cheers --- Jan
neng...@gmail.com
The results are updated now, including new results of SWI-Prolog and
Eclipse. It seems that the directive "nodbgcomp" is not working
anymore in Eclipse version 6.0. You need to compile a program using
the option "debug:off" to generate optimized code. I would propose
that all Prolog systems follow the SICStus tradition, i.e., using
[file] to generate code that can be traced and using compile(file) to
generate code that disenables debugging.
Cheers,
Neng-Fa
Mats Carlsson
> I would propose
> that all Prolog systems follow the SICStus tradition, i.e., using
> [file] to generate code that can be traced and using compile(file) to
> generate code that disenables debugging.
Actually, in the SICStus tradition, possibly dating back to Dec10
Prolog,
consult(File) will load File in interpreted form whereas compile(File)
will load it in compiled form. None of these forms disables
debugging,
but the interpreted form allows for somewhat more fine-grained
debugging,
since arithmetic and other things compiled in-line will be visible to
the debugger.
Nowadays, in SICStus, [File] is an alias for load_files(File).
--Mats
Jan Wielemaker
Its not a very ideal model. It works great for single-file programs
and might be a good thing from the commandline, but for many-file
projects you sometimes want to load the program in debug mode and
sometimes not and you probably don't want to change all directives.
Of course, systems also vary a lot in both how much different modes
differ in speed and how much these differ in supported debug
facilities. That might have affected the choices made by
implementors.
Cheers --- Jan
Neng-Fa Zhou
<neng...@gmail.com> wrote in message
news:0092d898-faf8-45ff...@u75g2000hsf.googlegroups.com...
> .. i.e., using [file] to generate code that can be traced and using
I meant using compile(file) to generate optimized code, which may also allow
debugging. Here are the options I used to compile programs with different
systems to generate the results (http://probp.com/performance.htm). Please
let me know if anybody knows there are other options that give better
performance.
B-Prolog: cl(File)
Eclipse: compile(File,[debug:off])
GNU-Prolog: [File] (I am aware that glpc generates native code but not used
because it does not support separate compilation)
SICStus: compile(File)
SWI-Prolog: start swi with the option "-O" and use [File] to load a program
XSB: [File]
YAP: [File]
Cheers,
Neng-Fa