Wikipedia made the following definition: "This list of JVM languages comprises computer programming languages that are used to produce software that runs on the Java Virtual Machine (JVM). Some of these languages are interpreted by a Java program, and some are compiled to Java bytecode and JIT-compiled during execution as regular Java programs to improve performance.".

So I guess Jekejeke Prolog falls under this category, but for example JPL from SWI-Prolog not. So I gave it a try and tested a couple of JVM Prolog systems. The screenshot shows the results. I tested the following JVM Prolog systems:

JIProlog: Version 3.1.0-2
tuProlog: Version 2.6
JLog: Version 1.3.6
Jekejeke: Version 0.9.6

Testing was not that easy. Non of the Prolog systems did support a statistics/2 system predicate. So to measure the time I had to invent something for each Prolog system. Further some test programs didn't work in all Prolog systems, so I removed them totally from the testing in order to allow for a total measurement. The test programs that cause problems were:

mtak: Didn't run on JIProlog. It causes some buffer overflow, but I couldn't figure how to increase the buffer size.
calc: Didn't run on JLog. Somehow it didn't correctly process the cut inside a DCG rule.

Also it appeared that many of the Prolog systems were picky, and for example didn't understand rem but only mod. tuProlog had the most problems with syntax, it forced me to write (N mod 2) =:= 0 instead of N mod 2 =:= 0, and it didn't allow the ^ as a functor. For testing I run my usual benchmarks, but divided the number of iterations by 10, so that I don't have to wait ages.

The good news is that these JVM Prologs are still better than the Android metal. The bad news is that their performans is still not very good compared to Jekejeke Prolog. So if I were to fall back to another Prolog system, I wouldn't choose one of the other JVM Prolog systems.

Previous Post on the Android Metal

Jekejeke Runtime: Strategies Comparison

#JVM #prolog #benchmark  
Anh Mather's profile photoJekejeke Logic Programming's profile photo
As hardware is getting faster ( I am a CPU design manager) , prolog becomes more useful. But I wish we will have a dedicate HW support for prolog engine some day! The performance issue is still a show stopper for any serious application. The situation of JIT translation of prolog code to WARM, to java to byte codes to machine code are just Too inefficient !

Yeah, doing it in Java is still challenging (no full controll over struct/array/union memory layout).

But I guess YAP proves that dedicated hardware is not necessary. Some testing I have done with compiling Prolog systems shows that YAP would run the above test suite in around 100 ms. But I wouldn't mind dedicated hardware.

YAP also shows indexing is vital, and to some extend Jekejeke Prolog. Both Prolog systems have JIT cascaded indexing. In indexing the focus is not only on generating clause code ("horizontal"), but on generating head matching structures ("vertical"). In JIT indexing you do it on the fly.

If I have time will also post the results for compiled Prolog systems.
Add a comment...