I am still fiddling around with (is)/2 implementation.--- Synchronet 3.20a-Linux NewsLink 1.114
Formerly Jekejeke Prolog had traditionally automatic
bridging and tunneling. This is all going down the drain,
we want to become more GNU Prolog compatible. Novacore
should be as puritanical as possible, namely a Prolog core that
has an upbringing that disapproves the suggar laced world of
formerly Jekejeke Prolog! Funny discovery, not all Prolog
systems throw the same evaluable errors. Here a little
discrepancy between GNU Prolog and SWI-Prolog:
/* GNU Prolog */
?- X is append(1,2).
uncaught exception: error(type_error(evaluable,append/2),(is)/2)
?- X is append([1,2],[3]).
uncaught exception: error(type_error(evaluable,append/2),(is)/2)
/* SWI-Prolog */
?- X is append(1,2).
ERROR: Arithmetic: `append/2' is not a function
?- X is append([1,2],[3]).
ERROR: Type error: `[]' expected, found `[1,2]' (a list)
("x" must hold one character)
I started using this test case:--- Synchronet 3.20a-Linux NewsLink 1.114
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
The internal call is tail recursive I guess, since the functor is--- Synchronet 3.20a-Linux NewsLink 1.114
already checked, and a looked up handle, a function pointer,
causes the evaluation. Recently GNU Prolog has moved to GitHub,
so I can find the source code of GNU Prolog stuff more easily, things
like Load_Math_Expression. But I think the GNU Prolog approach is
only feasible, if you dare to rely on the native stack.
Concerning the new Java foreign function interface. I switched
from handles obtained by method reflection to handles that were
populated via functional interfaces. Its an itch faster, and close
to SWI-Prolog optimised, but only for JDK 8:
/* Jekejeke Prolog, 1.6.3, JDK 8, Functional Interface */
?- time(test).
% Time 171 ms, GC 2 ms, Wall 09/09/2023 22:04
true.
The above uses the native stack like GNU Prolog and no
cycle testing nothing. But I guess it burns CPU since it uses
two pointers to represent a term. I hope I can soon get rid of that.
Another brake could be the varargs array allocation.
Mild Shock schrieb am Samstag, 9. September 2023 um 22:17:13 UTC+2:
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
Ok there is a big confusion in SWI-Prolog discourse, I was--- Synchronet 3.20a-Linux NewsLink 1.114
mentioning native stack, and people think I was talking
about native code. Holy cow! Do I speak chinese, or what?
Just look for yourself. Step 1: Go to GNU Prolog GitHub,
Step 2: Lookup the C function Load_Math_Expression
Interesting find, for Dogelog Player on CPython so far:
/* Dogelog Player 1.1.1, CPython */
?- X=1+X, Y is X.
Unknown exception: 'maximum recursion depth exceeded'
What does PyPy do? What does JavaScript do? How do we
handle this exception. Are there more candidates than only (is)/2,
like for example copy_term/2, etc.. This would cover Dogelog
Player. What about formerly Jekejeke Prolog, respectively Java?
Mild Shock schrieb am Samstag, 9. September 2023 um 22:18:21 UTC+2:
The internal call is tail recursive I guess, since the functor is
already checked, and a looked up handle, a function pointer,
causes the evaluation. Recently GNU Prolog has moved to GitHub,
so I can find the source code of GNU Prolog stuff more easily, things
like Load_Math_Expression. But I think the GNU Prolog approach is
only feasible, if you dare to rely on the native stack.
Concerning the new Java foreign function interface. I switched
from handles obtained by method reflection to handles that were
populated via functional interfaces. Its an itch faster, and close
to SWI-Prolog optimised, but only for JDK 8:
/* Jekejeke Prolog, 1.6.3, JDK 8, Functional Interface */
?- time(test).
% Time 171 ms, GC 2 ms, Wall 09/09/2023 22:04
true.
The above uses the native stack like GNU Prolog and no
cycle testing nothing. But I guess it burns CPU since it uses
two pointers to represent a term. I hope I can soon get rid of that.
Another brake could be the varargs array allocation.
Mild Shock schrieb am Samstag, 9. September 2023 um 22:17:13 UTC+2:
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
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 920 |
Nodes: | 10 (1 / 9) |
Uptime: | 75:20:42 |
Calls: | 12,187 |
Calls today: | 2 |
Files: | 186,526 |
Messages: | 2,236,832 |