I am prototyping some new functionality for our product. To have
arguments if somebody asks (again...)  the question "Why we are using
this obsolete, interpreted, slow scripting language named Prolog" I
implemented the same algorithm in Prolog (SICStus 4.1) and Java 6.

Prolog version is "research prototype" written with my left foot,
without any optimization. Java code is very highly optimized, actually
to the "last drop"

Here are the results

SIZE	PROLOG	JAVA
10	219	610
20	359	660
50	828	1795
100	1672	3312

Time is in milliseconds.

This is not CLP application. I have some partial results comparing
Prolog and Java  using one of the open source Java constraint
packages: generation of domain variables in Java took more time than
Prolog needed to solve the whole problem. I am not attaching numbers,
because test is not complete

A.L.

On 2010-01-12, A.L <alewando@aol.com> wrote:
> I am prototyping some new functionality for our product. To have
> arguments if somebody asks (again...)  the question "Why we are using
> this obsolete, interpreted, slow scripting language named Prolog" I
> implemented the same algorithm in Prolog (SICStus 4.1) and Java 6.
>
> Prolog version is "research prototype" written with my left foot,
> without any optimization. Java code is very highly optimized, actually
> to the "last drop"
>
> Here are the results
>
> SIZE	PROLOG	JAVA
> 10	219	610
> 20	359	660
> 50	828	1795
> 100	1672	3312
>
> Time is in milliseconds.
>
> This is not CLP application. I have some partial results comparing
> Prolog and Java  using one of the open source Java constraint
> packages: generation of domain variables in Java took more time than
> Prolog needed to solve the whole problem. I am not attaching numbers,
> because test is not complete

Nice to hear this.  Of course, it gets a lot stronger if you include the code,
so both Prolog and Java programmers can try to do it better.

	Cheers --- Jan

On 12 Jan 2010 16:03:13 GMT, Jan Wielemaker <janw@hppc323.few.vu.nl>
wrote:

>On 2010-01-12, A.L <alewando@aol.com> wrote:
>> I am prototyping some new functionality for our product. To have
>> arguments if somebody asks (again...)  the question "Why we are using
>> this obsolete, interpreted, slow scripting language named Prolog" I
>> implemented the same algorithm in Prolog (SICStus 4.1) and Java 6.
>>
>> Prolog version is "research prototype" written with my left foot,
>> without any optimization. Java code is very highly optimized, actually
>> to the "last drop"
>>
>> Here are the results
>>
>> SIZE	PROLOG	JAVA
>> 10	219	610
>> 20	359	660
>> 50	828	1795
>> 100	1672	3312
>>
>> Time is in milliseconds.
>>
>> This is not CLP application. I have some partial results comparing
>> Prolog and Java  using one of the open source Java constraint
>> packages: generation of domain variables in Java took more time than
>> Prolog needed to solve the whole problem. I am not attaching numbers,
>> because test is not complete
>
>Nice to hear this.  Of course, it gets a lot stronger if you include the code,
>so both Prolog and Java programmers can try to do it better.

Sorry, I cannot do this. There is no "academic freedom" in
corporation...

A.L.

On Tue, 12 Jan 2010 10:22:44 -0600, A.L. wrote:

>>> SIZE	PROLOG	JAVA
>>> 10	219	610
>>> 20	359	660
>>> 50	828	1795
>>> 100	1672	3312
[..]
>>Nice to hear this.  Of course, it gets a lot stronger if you include the
>>code, so both Prolog and Java programmers can try to do it better.
> 
> Sorry, I cannot do this. There is no "academic freedom" in
> corporation...

Then, of course, academia will have to ignore your claim. And industry
must dismiss it as well I presume.

More to the point ...
Here is a story from the 80-ties - I might mix up some details, but the
gist is correct.
Someone wrote a theorem prover in C - pleasing performance.
Then someone (was it Mats ?) rewrote that theorem prover in SICStus Prolog, 
and the performance was way better.
Then Andre Marien did some local changes to the original C-code and the
performance did beat the Prolog version.


Here is another story from the eighties (and I am sure many people
have a similar story).
We once held a contest in our group: a particular problem (something with
filling out a cross-word puzzle) was done in Pascal by Stef Renkens, and I 
was doing a Prolog version of it (no constraints yet). During a few rounds,
I would come up with a faster Prolog program in half an hour, after which it
took Stef another day in Pascal to catch up with me and beat me.

Instead of looking at who beats who, one could try to learn something from
those "language" competitions. For me it is this:

	- you want to write a program with reasonable performance quickly,
		go for Prolog, not C or Pascal
	- rewriting the Prolog program in C or Pascal will most probably 
		improve speed (why ? (*)) but it needs to be done by someone
		understanding Prolog, C or Pascal and most importantly also
		the Prolog program - i.e. the rewriter can't be an average 
		programmer; it is a manager's decision whether the rewrite
		is worth it - and the manager usually makes the wrong 
		decision :-)


(*) because while rewriting it, one can take into account types and modes
actually, if that's not the case, the rewrite will be almost impossible, because
one ends up writing another Prolog engine

Cheers

Bart Demoen

bart demoen schrieb:

> 	- you want to write a program with reasonable performance quickly,
> 		go for Prolog, not C or Pascal
> 	- rewriting the Prolog program in C or Pascal will most probably 
> 		improve speed (why ? (*)) but it needs to be done by someone
> 		understanding Prolog, C or Pascal and most importantly also
> 		the Prolog program - i.e. the rewriter can't be an average 
> 		programmer; it is a manager's decision whether the rewrite
> 		is worth it - and the manager usually makes the wrong 
> 		decision :-)

Sounds like a good prototyping strategy. Make your prototype
first with Prolog and then move to an other
programming language.

I would add to it, that one can also create hybrids, sometimes
it might be of advantage to only rewrite a part of the program
and still rely in other parts on Prolog.

Bye

On Wed, 13 Jan 2010 01:34:45 +0100, Jan Burse <janburse@fastmail.fm>
wrote:

>bart demoen schrieb:
>
>> 	- you want to write a program with reasonable performance quickly,
>> 		go for Prolog, not C or Pascal
>> 	- rewriting the Prolog program in C or Pascal will most probably 
>> 		improve speed (why ? (*)) but it needs to be done by someone
>> 		understanding Prolog, C or Pascal and most importantly also
>> 		the Prolog program - i.e. the rewriter can't be an average 
>> 		programmer; it is a manager's decision whether the rewrite
>> 		is worth it - and the manager usually makes the wrong 
>> 		decision :-)

With all respect, Mr. Demoen, I am talking about Java not C++ or
Pascal. Rewritting to Java doesn't improve speed (why?...) in most
cases.

A.L.

On Jan 12, 10:39=A0am, A.L. <alewa...@aol.com> wrote:


> This is not CLP application. I have some partial results comparing
> Prolog and Java =A0using one of the open source Java constraint
> packages: generation of domain variables in Java took more time than
> Prolog needed to solve the whole problem. I am not attaching numbers,
> because test is not complete
>

That means that the benchmark you used is not a good one. Some systems
spend time preprocessing constraints for faster propagation and thus
require more time to generate constraints.

Cheers,
Neng-Fa

On Tue, 12 Jan 2010 20:10:29 -0800 (PST), afa <neng.zhou@gmail.com>
wrote:

>On Jan 12, 10:39�am, A.L. <alewa...@aol.com> wrote:
>
>
>> This is not CLP application. I have some partial results comparing
>> Prolog and Java �using one of the open source Java constraint
>> packages: generation of domain variables in Java took more time than
>> Prolog needed to solve the whole problem. I am not attaching numbers,
>> because test is not complete
>>
>
>That means that the benchmark you used is not a good one. Some systems
>spend time preprocessing constraints for faster propagation and thus
>require more time to generate constraints.
>

Not in this case. Domain variables are implemented in Java using
generic collections, and these are rather slow and not very efficiient

A.L.

On Tue, 12 Jan 2010 19:58:59 -0600, A.L. wrote:


> With all respect, Mr. Demoen, I am talking about Java not C++ or Pascal.
> Rewritting to Java doesn't improve speed (why?...) in most cases.

Why ? Because the person doing the rewrite uses inherently slow packages:
you say it yourself in a later post. I wouldn't call such Java programs 
"higly optimized to the last drop".

All evidence shows that one can write programs in Java with speed very
close to C++.

Cheers

Bart Demoen