@MSGID:
<5848823c-8c71-4d67-8dc0-42a72aaa95acn@googlegroups.com> 57ac3530
@REPLY:
<a6ed877b-5d7d-4404-b41c-ee58c12ba6a0n@googlegroups.com> d64e1f08
@REPLYADDR Mild Shock <bursejan@gmail.com>
@REPLYTO 2:5075/128 Mild Shock
@CHRS: CP866 2
@RFC: 1 0
@RFC-References:
<616590d2-4927-4f60-ba91-acef849695a3n@googlegroups.com> <b4fe1397-91ae-472c-9365-dbd8e0937f27n@googlegroups.com>
<a6ed877b-5d7d-4404-b41c-ee58c12ba6a0n@googlegroups.com>
@RFC-Message-ID:
<5848823c-8c71-4d67-8dc0-42a72aaa95acn@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
I started using this test case:

test :-
   between(0,1000000,N),
     is exp(1+N/1000000),
   fail.
test.

To test a new Java foreign function interface. I then
observed that SWI-Prolog stack engine causes
a little overhead:

/* SWI-Prolog, 9.1.14, optimise=false */
?- time(test).
% 2,000,001 inferences, 0.313 CPU in 0.315 seconds
(99% CPU, 6400003 Lips)
true.

/* SWI-Prolog, 9.1.14, optimise=true */
?- time(test).
% 1,000,002 inferences, 0.172 CPU in 0.176 seconds
(98% CPU, 5818193 Lips)
true.

Intrestingly GNU Prolog doesn`t use a stack engine,
just relies on the native stack. Its quite speedy without
any optimisation:

/* GNU Prolog 1.5.0 (64 bits) */
?- test.
(125 ms) yes
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441