Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > sci.math > #639319 > unrolled thread

Novacore goes Bisimulation: Scryer Prolog is Slow!

Back to article view | Back to sci.math

Contents

  Novacore goes Bisimulation: Scryer Prolog is Slow! Mild Shock <janburse@fastmail.fm> - 2025-07-25 14:30 +0200
    Is Mild Shock going rogue? (Re: Novacore goes Bisimulation: Scryer Prolog is Slow!) Mild Shock <janburse@fastmail.fm> - 2025-07-25 14:32 +0200
      Is Mostowski Collapse a professional mathematician (Re: Is Mild Shock going rogue?) Mild Shock <janburse@fastmail.fm> - 2025-07-25 14:32 +0200
        New Project Name: NovaCore becomes VibeCore (Re: Is Mostowski Collapse a professional mathematician) Mild Shock <janburse@fastmail.fm> - 2025-07-25 14:43 +0200
    The End of Deutsch-Schorr-Waite [cycle_detection.rs] (Re: Novacore goes Bisimulation: Scryer Prolog is Slow!) Mild Shock <janburse@fastmail.fm> - 2025-07-28 10:51 +0200
      Backtracking Branching Association List (Was: The End of Deutsch-Schorr-Waite [cycle_detection.rs]) Mild Shock <janburse@fastmail.fm> - 2025-07-28 10:57 +0200
        Do it like in acyclic_decompose/3 (Was: Backtracking Branching Association List) Mild Shock <janburse@fastmail.fm> - 2025-07-28 11:39 +0200
          Cache-Trashing vs Cache-Friendly [Code Example] (Re: Do it like in acyclic_decompose/3) Mild Shock <janburse@fastmail.fm> - 2025-07-28 17:27 +0200
      Re: The End of Deutsch-Schorr-Waite [cycle_detection.rs] (Re: Novacore goes Bisimulation: Scryer Prolog is Slow!) Jordon Molokovsky <ovm@lorr.ru> - 2025-07-28 12:56 +0000
        I guess your brain was "overheating" (Re: The End of Deutsch-Schorr-Waite [cycle_detection.rs]) Mild Shock <janburse@fastmail.fm> - 2025-07-28 17:17 +0200
          Re: I guess your brain was "overheating" (Re: The End of Deutsch-Schorr-Waite [cycle_detection.rs]) Alton Grammatakakis <kl@aaasi.gr> - 2025-07-28 16:09 +0000
            The difference is only in one letter "t" or "d" (Was: I guess your brain was "overheating") Mild Shock <janburse@fastmail.fm> - 2025-07-28 21:17 +0200
            Re: You literally wrote "overheat" (Re: I guess your brain was "overheating" (Re: The End of Deutsch-Schorr-Waite [cycle_detection.rs]) Neury Valetov <ntt@uovrav.ru> - 2025-07-28 19:44 +0000
              Don't put large memory in your computer it might "overheat" (Re: You literally wrote "overheat") Mild Shock <janburse@fastmail.fm> - 2025-07-29 15:57 +0200
              Re: Don't put large memory in your computer it might "overheat" (Was: You literally wrote "overheat") Mizraim Zelenenkov <iall@zm.ru> - 2025-07-29 16:00 +0000
                Why Russ Bots Again: Micro Penis? (Was: Don't put large memory in your computer it might "overheat" ) Mild Shock <janburse@fastmail.fm> - 2025-07-29 23:16 +0200
        Re: I guess your brain was "overheating" (Re: The End of Deutsch-Schorr-Waite [cycle_detection.rs]) Emile Paduchev <mcc@clleeeme.ru> - 2025-07-28 15:53 +0000
          You literally wrote "overheat" (Was: I guess your brain was "overheating") Mild Shock <janburse@fastmail.fm> - 2025-07-28 21:19 +0200
      Entering the Age of Rational Trees (2025) (Re: The End of Deutsch-Schorr-Waite [cycle_detection.rs]) Mild Shock <janburse@fastmail.fm> - 2025-08-16 13:05 +0200
    The pairs are nasty, otherwise not always slow! (Re: Novacore goes Bisimulation: Scryer Prolog is Slow!) Mild Shock <janburse@fastmail.fm> - 2025-07-30 14:44 +0200
    It was painful for my GC, but fixed now (Was: The pairs are nasty, otherwise not always slow!) Mild Shock <janburse@fastmail.fm> - 2025-07-30 14:49 +0200

Page 1 of 2  [1] 2  Next page →

#639319 — Novacore goes Bisimulation: Scryer Prolog is Slow!

Hi,

Having fun with Bisimulation, and a new test
suite of nasty circular pairs. But how store
circular pairs, if clauses do not support

circular terms. Well chop it up into equations,
I create 1000 such equation pairs:

test([A = c(A, B), C = c(A, D), E = n, _ = c(F, B),
       F = c(C, C), G = c(G, D), D = c(E, C), B = n],
      [H = c(H, I), J = c(K, I), L = c(L, I), I = c(M, N),
       O = c(K, J), N = n, K = c(K, J), M = c(K, O)]).
Etc..

The pairs are nasty because the usual compare_with_stack/2
chokes on them. Here some results:

/* SWI-Prolog 9.3.26 */
?- time((between(1,30,_), part, fail; true)).
% 540,118 inferences, 0.047 CPU in 0.041 seconds (115% CPU, 11522517 Lips)
true.

/* Trealla Prolog 2.78.40 */
?- time((between(1,30,_), part, fail; true)).
% Time elapsed 0.113s, 1143903 Inferences, 10.157 MLips
    true.

/* Scryer Prolog 0.9.4-417 */
?- time((between(1,30,_), part, fail; true)).
    % CPU time: 0.226s, 1_117_809 inferences
    true.

/* Dogelog Player 1.3.5 */
?- time((between(1,30,_), part2, fail; true)).
% Zeit 309 ms, GC 0 ms, Lips 8693718, Uhr 25.07.2025 13:47
true.

The amazing thing is, I compared a 100% Prolog
implementation, so there is a lot of head room
for improvement:

part2 :-
    bitest(X,Y), X ~~ Y, fail; true.

The operator (~~)/2 is part of library(math),
and has been implemented with same_term/2 so far.

Bye

[toc] | [next] | [standalone]

#639320 — Is Mild Shock going rogue? (Re: Novacore goes Bisimulation: Scryer Prolog is Slow!)

Hi,

Is Mild Shock going rogue? Not really,
I am only amused that a couple of academic
frauds like these here:

- Bart Demoen

- Ulrich Neumerkel

- Paulo Moura

- Joseph Vidal-Rosset

Think they can oppress what they view a
non-academic. Its more explicit in what
Bart Demoen wrote back then, but more

implicit how the above morons act. For
example blocking me from all repositories,
making it impossible for me to raise issues,

and strangly discussion by dogmatic nonsense,
doesn't increase the willingness of the
harassed person to share something:

What occurs-check optimizations is SWI Prolog using?
https://stackoverflow.com/a/65620337/17524790

Also that gists would be found on
archive.org is nonsense.

Bye

Mild Shock schrieb:
> Hi,
> 
> Having fun with Bisimulation, and a new test
> suite of nasty circular pairs. But how store
> circular pairs, if clauses do not support
> 
> circular terms. Well chop it up into equations,
> I create 1000 such equation pairs:
> 
> test([A = c(A, B), C = c(A, D), E = n, _ = c(F, B),
>        F = c(C, C), G = c(G, D), D = c(E, C), B = n],
>       [H = c(H, I), J = c(K, I), L = c(L, I), I = c(M, N),
>        O = c(K, J), N = n, K = c(K, J), M = c(K, O)]).
> Etc..
> 
> The pairs are nasty because the usual compare_with_stack/2
> chokes on them. Here some results:
> 
> /* SWI-Prolog 9.3.26 */
> ?- time((between(1,30,_), part, fail; true)).
> % 540,118 inferences, 0.047 CPU in 0.041 seconds (115% CPU, 11522517 Lips)
> true.
> 
> /* Trealla Prolog 2.78.40 */
> ?- time((between(1,30,_), part, fail; true)).
> % Time elapsed 0.113s, 1143903 Inferences, 10.157 MLips
>     true.
> 
> /* Scryer Prolog 0.9.4-417 */
> ?- time((between(1,30,_), part, fail; true)).
>     % CPU time: 0.226s, 1_117_809 inferences
>     true.
> 
> /* Dogelog Player 1.3.5 */
> ?- time((between(1,30,_), part2, fail; true)).
> % Zeit 309 ms, GC 0 ms, Lips 8693718, Uhr 25.07.2025 13:47
> true.
> 
> The amazing thing is, I compared a 100% Prolog
> implementation, so there is a lot of head room
> for improvement:
> 
> part2 :-
>     bitest(X,Y), X ~~ Y, fail; true.
> 
> The operator (~~)/2 is part of library(math),
> and has been implemented with same_term/2 so far.
> 
> Bye

[toc] | [prev] | [next] | [standalone]

#639321 — Is Mostowski Collapse a professional mathematician (Re: Is Mild Shock going rogue?)

Mild Shock schrieb:
> Hi,
> 
> Is Mild Shock going rogue? Not really,
> I am only amused that a couple of academic
> frauds like these here:
> 
> - Bart Demoen
> 
> - Ulrich Neumerkel
> 
> - Paulo Moura
> 
> - Joseph Vidal-Rosset
> 
> Think they can oppress what they view a
> non-academic. Its more explicit in what
> Bart Demoen wrote back then, but more
> 
> implicit how the above morons act. For
> example blocking me from all repositories,
> making it impossible for me to raise issues,
> 
> and strangly discussion by dogmatic nonsense,
> doesn't increase the willingness of the
> harassed person to share something:
> 
> What occurs-check optimizations is SWI Prolog using?
> https://stackoverflow.com/a/65620337/17524790
> 
> Also that gists would be found on
> archive.org is nonsense.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Having fun with Bisimulation, and a new test
>> suite of nasty circular pairs. But how store
>> circular pairs, if clauses do not support
>>
>> circular terms. Well chop it up into equations,
>> I create 1000 such equation pairs:
>>
>> test([A = c(A, B), C = c(A, D), E = n, _ = c(F, B),
>>        F = c(C, C), G = c(G, D), D = c(E, C), B = n],
>>       [H = c(H, I), J = c(K, I), L = c(L, I), I = c(M, N),
>>        O = c(K, J), N = n, K = c(K, J), M = c(K, O)]).
>> Etc..
>>
>> The pairs are nasty because the usual compare_with_stack/2
>> chokes on them. Here some results:
>>
>> /* SWI-Prolog 9.3.26 */
>> ?- time((between(1,30,_), part, fail; true)).
>> % 540,118 inferences, 0.047 CPU in 0.041 seconds (115% CPU, 11522517 
>> Lips)
>> true.
>>
>> /* Trealla Prolog 2.78.40 */
>> ?- time((between(1,30,_), part, fail; true)).
>> % Time elapsed 0.113s, 1143903 Inferences, 10.157 MLips
>>     true.
>>
>> /* Scryer Prolog 0.9.4-417 */
>> ?- time((between(1,30,_), part, fail; true)).
>>     % CPU time: 0.226s, 1_117_809 inferences
>>     true.
>>
>> /* Dogelog Player 1.3.5 */
>> ?- time((between(1,30,_), part2, fail; true)).
>> % Zeit 309 ms, GC 0 ms, Lips 8693718, Uhr 25.07.2025 13:47
>> true.
>>
>> The amazing thing is, I compared a 100% Prolog
>> implementation, so there is a lot of head room
>> for improvement:
>>
>> part2 :-
>>     bitest(X,Y), X ~~ Y, fail; true.
>>
>> The operator (~~)/2 is part of library(math),
>> and has been implemented with same_term/2 so far.
>>
>> Bye
> 

[toc] | [prev] | [next] | [standalone]

#639322 — New Project Name: NovaCore becomes VibeCore (Re: Is Mostowski Collapse a professional mathematician)

Hi,

On the occassion of bisimulation introduction
in library(math), I have to also make another
announcement. There is a new Project name:

- Sadly novacore.ch was taken, and
   we had to go with novacuor.ch

- Switzerland has already to many Novas,
   Novartis, Nova-that, Nova-this, etc..

- Prolog and the core is not really new.
   Even bisimulation is not really new.

- So lets try something new VibeCore,
   admitedly inspired by Vibe Coding...

- Lets see how we can put live into the
   name "vibe". Currently I find:

"Karpathy described it as "fully giving
in to the vibes, embracing exponentials,
and forgetting that the code even exists."

Ha Ha, compare_with_stack, has an similar
vibe, doesn't work for the pairs, one
has to go with compare_with_memo.

VibeCore hints to a future with more
computing power and a different view on
explorative problem solving.

Bye

Mild Shock schrieb:
> Mild Shock schrieb:
>> Hi,
>>
>> Is Mild Shock going rogue? Not really,
>> I am only amused that a couple of academic
>> frauds like these here:
>>
>> - Bart Demoen
>>
>> - Ulrich Neumerkel
>>
>> - Paulo Moura
>>
>> - Joseph Vidal-Rosset
>>
>> Think they can oppress what they view a
>> non-academic. Its more explicit in what
>> Bart Demoen wrote back then, but more
>>
>> implicit how the above morons act. For
>> example blocking me from all repositories,
>> making it impossible for me to raise issues,
>>
>> and strangly discussion by dogmatic nonsense,
>> doesn't increase the willingness of the
>> harassed person to share something:
>>
>> What occurs-check optimizations is SWI Prolog using?
>> https://stackoverflow.com/a/65620337/17524790
>>
>> Also that gists would be found on
>> archive.org is nonsense.
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> Having fun with Bisimulation, and a new test
>>> suite of nasty circular pairs. But how store
>>> circular pairs, if clauses do not support
>>>
>>> circular terms. Well chop it up into equations,
>>> I create 1000 such equation pairs:
>>>
>>> test([A = c(A, B), C = c(A, D), E = n, _ = c(F, B),
>>>        F = c(C, C), G = c(G, D), D = c(E, C), B = n],
>>>       [H = c(H, I), J = c(K, I), L = c(L, I), I = c(M, N),
>>>        O = c(K, J), N = n, K = c(K, J), M = c(K, O)]).
>>> Etc..
>>>
>>> The pairs are nasty because the usual compare_with_stack/2
>>> chokes on them. Here some results:
>>>
>>> /* SWI-Prolog 9.3.26 */
>>> ?- time((between(1,30,_), part, fail; true)).
>>> % 540,118 inferences, 0.047 CPU in 0.041 seconds (115% CPU, 11522517 
>>> Lips)
>>> true.
>>>
>>> /* Trealla Prolog 2.78.40 */
>>> ?- time((between(1,30,_), part, fail; true)).
>>> % Time elapsed 0.113s, 1143903 Inferences, 10.157 MLips
>>>     true.
>>>
>>> /* Scryer Prolog 0.9.4-417 */
>>> ?- time((between(1,30,_), part, fail; true)).
>>>     % CPU time: 0.226s, 1_117_809 inferences
>>>     true.
>>>
>>> /* Dogelog Player 1.3.5 */
>>> ?- time((between(1,30,_), part2, fail; true)).
>>> % Zeit 309 ms, GC 0 ms, Lips 8693718, Uhr 25.07.2025 13:47
>>> true.
>>>
>>> The amazing thing is, I compared a 100% Prolog
>>> implementation, so there is a lot of head room
>>> for improvement:
>>>
>>> part2 :-
>>>     bitest(X,Y), X ~~ Y, fail; true.
>>>
>>> The operator (~~)/2 is part of library(math),
>>> and has been implemented with same_term/2 so far.
>>>
>>> Bye
>>
> 

[toc] | [prev] | [next] | [standalone]

#639380 — The End of Deutsch-Schorr-Waite [cycle_detection.rs] (Re: Novacore goes Bisimulation: Scryer Prolog is Slow!)

Hi,

Assume that we live in a world where we
have excess memory. So we can afford stacks!
And then make the crucial observation,

we can use the stack of the Prolog engine,
no need to create an artificial stack in C,
or use the native stack of C.

I guess SWI-Prolog has already groked the
first we can "afford stacks". But did anybody
already grok the "100% Prolog" idea?

Well we are not yet there 100% Prolog
has still an overhead. Here is a little
test acyclic_term/2:

/* SWI-Prolog 9.3.26, C Stacks and/or Agendas */
?- time((between(1,30,_), acyclic2, fail; true)).
% 330,150 inferences, 0.016 CPU in 0.023 seconds
(69% CPU, 21129600 Lips)
true.

/* Trealla Prolog 2.79.6, ?? */
?- time((between(1,30,_), acyclic2, fail; true)).
% Time elapsed 0.063s, 643413 Inferences, 10.166 MLips
    true.

/* Dogelog Player 1.3.5, 100% Prolog */
?- time((between(1,30,_), acyclic2, fail; true)).
% Zeit 115 ms, GC 0 ms, Lips 11803904, Uhr 28.07.2025 10:03
true.

/* Scryer Prolog 0.9.4-417, Deutsch-Schorr-Waite  */
?- time((between(1,30,_), acyclic2, fail; true)).
% CPU time: 0.130s, 626_829 inferences
true.

Bye

[toc] | [prev] | [next] | [standalone]

#639381 — Backtracking Branching Association List (Was: The End of Deutsch-Schorr-Waite [cycle_detection.rs])

Hi,

So the 115 ms by Dogelog Player are faster than the
0.130s by Scryer Prolog. Quite amazing! From
Dogelog Player library(math):

/**
  * acyclic_term(T): [TC2 8.3.11]
  * The predicate succeeds when the Prolog term T is an acyclic term,
  * otherwise the predicate fails.
  */
% acyclic_term(+Term)
acyclic_term(X) :- sys_cyclic_term(X, []), !, fail.
acyclic_term(_).

% sys_cyclic_term(+Term, +List)
sys_cyclic_term(X, S) :- compound(X),
    member(Y, S),
    same_term(X, Y), !.
sys_cyclic_term(X, S) :- compound(X),
    X =.. [_|L],
    member(Y, L),
    sys_cyclic_term(Y, [X|S]).

Algorithms that implicitly detect sharing cannot
do much? Since we only need to find a first cycle?
Also a challenge to bring the association list to
native and lets say turn it into a hash table,

don't know yet when and how even somebody would
attempt that. Big advantage of anything not using
Deutsch-Schorr-Waite , no write operation into the
given term. Write operation are sometimes

poison for the CPU and the RAM.

Bye

Mild Shock schrieb:
> Hi,
> 
> Assume that we live in a world where we
> have excess memory. So we can afford stacks!
> And then make the crucial observation,
> 
> we can use the stack of the Prolog engine,
> no need to create an artificial stack in C,
> or use the native stack of C.
> 
> I guess SWI-Prolog has already groked the
> first we can "afford stacks". But did anybody
> already grok the "100% Prolog" idea?
> 
> Well we are not yet there 100% Prolog
> has still an overhead. Here is a little
> test acyclic_term/2:
> 
> /* SWI-Prolog 9.3.26, C Stacks and/or Agendas */
> ?- time((between(1,30,_), acyclic2, fail; true)).
> % 330,150 inferences, 0.016 CPU in 0.023 seconds
> (69% CPU, 21129600 Lips)
> true.
> 
> /* Trealla Prolog 2.79.6, ?? */
> ?- time((between(1,30,_), acyclic2, fail; true)).
> % Time elapsed 0.063s, 643413 Inferences, 10.166 MLips
>     true.
> 
> /* Dogelog Player 1.3.5, 100% Prolog */
> ?- time((between(1,30,_), acyclic2, fail; true)).
> % Zeit 115 ms, GC 0 ms, Lips 11803904, Uhr 28.07.2025 10:03
> true.
> 
> /* Scryer Prolog 0.9.4-417, Deutsch-Schorr-Waite  */
> ?- time((between(1,30,_), acyclic2, fail; true)).
> % CPU time: 0.130s, 626_829 inferences
> true.
> 
> Bye

[toc] | [prev] | [next] | [standalone]

#639382 — Do it like in acyclic_decompose/3 (Was: Backtracking Branching Association List)

Hi,

Interstingly there is an obvious way how
to do it without a braching association list,
that has different futures so to speack,

the below code repeatedly generates
dfferent association lists via [X|S].
We could of course instead do a threading

of the association list through some predicate,
and use some state on each entry inside the
association list, similar like in acyclic_decompose/3

we used a threading and entry state.

Bye

Mild Shock schrieb:
> Hi,
> 
> So the 115 ms by Dogelog Player are faster than the
> 0.130s by Scryer Prolog. Quite amazing! From
> Dogelog Player library(math):
> 
> /**
>   * acyclic_term(T): [TC2 8.3.11]
>   * The predicate succeeds when the Prolog term T is an acyclic term,
>   * otherwise the predicate fails.
>   */
> % acyclic_term(+Term)
> acyclic_term(X) :- sys_cyclic_term(X, []), !, fail.
> acyclic_term(_).
> 
> % sys_cyclic_term(+Term, +List)
> sys_cyclic_term(X, S) :- compound(X),
>     member(Y, S),
>     same_term(X, Y), !.
> sys_cyclic_term(X, S) :- compound(X),
>     X =.. [_|L],
>     member(Y, L),
>     sys_cyclic_term(Y, [X|S]).
> 
> Algorithms that implicitly detect sharing cannot
> do much? Since we only need to find a first cycle?
> Also a challenge to bring the association list to
> native and lets say turn it into a hash table,
> 
> don't know yet when and how even somebody would
> attempt that. Big advantage of anything not using
> Deutsch-Schorr-Waite , no write operation into the
> given term. Write operation are sometimes
> 
> poison for the CPU and the RAM.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> Assume that we live in a world where we
>> have excess memory. So we can afford stacks!
>> And then make the crucial observation,
>>
>> we can use the stack of the Prolog engine,
>> no need to create an artificial stack in C,
>> or use the native stack of C.
>>
>> I guess SWI-Prolog has already groked the
>> first we can "afford stacks". But did anybody
>> already grok the "100% Prolog" idea?
>>
>> Well we are not yet there 100% Prolog
>> has still an overhead. Here is a little
>> test acyclic_term/2:
>>
>> /* SWI-Prolog 9.3.26, C Stacks and/or Agendas */
>> ?- time((between(1,30,_), acyclic2, fail; true)).
>> % 330,150 inferences, 0.016 CPU in 0.023 seconds
>> (69% CPU, 21129600 Lips)
>> true.
>>
>> /* Trealla Prolog 2.79.6, ?? */
>> ?- time((between(1,30,_), acyclic2, fail; true)).
>> % Time elapsed 0.063s, 643413 Inferences, 10.166 MLips
>>     true.
>>
>> /* Dogelog Player 1.3.5, 100% Prolog */
>> ?- time((between(1,30,_), acyclic2, fail; true)).
>> % Zeit 115 ms, GC 0 ms, Lips 11803904, Uhr 28.07.2025 10:03
>> true.
>>
>> /* Scryer Prolog 0.9.4-417, Deutsch-Schorr-Waite  */
>> ?- time((between(1,30,_), acyclic2, fail; true)).
>> % CPU time: 0.130s, 626_829 inferences
>> true.
>>
>> Bye
> 

[toc] | [prev] | [next] | [standalone]

#639385 — Cache-Trashing vs Cache-Friendly [Code Example] (Re: Do it like in acyclic_decompose/3)

 > Write operation are sometimes
 > poison for the CPU and the RAM.

Try this where SIZE is a prime number:

/* Cache-Trashing Example */
void column_major_access() {
     for (int col = 0; col < SIZE; col++) {
         for (int row = 0; row < SIZE; row++) {
             matrix[row][col] += 1;
         }
     }
}

/* Cache-Friendly Example */
void row_major_access() {
     for (int row = 0; row < SIZE; row++) {
         for (int col = 0; col < SIZE; col++) {
             matrix[row][col] += 1;
         }
     }
}

Mild Shock schrieb:
> Hi,
> 
> Interstingly there is an obvious way how
> to do it without a braching association list,
> that has different futures so to speack,
> 
> the below code repeatedly generates
> dfferent association lists via [X|S].
> We could of course instead do a threading
> 
> of the association list through some predicate,
> and use some state on each entry inside the
> association list, similar like in acyclic_decompose/3
> 
> we used a threading and entry state.
> 
> Bye
> 
> Mild Shock schrieb:
>> Hi,
>>
>> So the 115 ms by Dogelog Player are faster than the
>> 0.130s by Scryer Prolog. Quite amazing! From
>> Dogelog Player library(math):
>>
>> /**
>>   * acyclic_term(T): [TC2 8.3.11]
>>   * The predicate succeeds when the Prolog term T is an acyclic term,
>>   * otherwise the predicate fails.
>>   */
>> % acyclic_term(+Term)
>> acyclic_term(X) :- sys_cyclic_term(X, []), !, fail.
>> acyclic_term(_).
>>
>> % sys_cyclic_term(+Term, +List)
>> sys_cyclic_term(X, S) :- compound(X),
>>     member(Y, S),
>>     same_term(X, Y), !.
>> sys_cyclic_term(X, S) :- compound(X),
>>     X =.. [_|L],
>>     member(Y, L),
>>     sys_cyclic_term(Y, [X|S]).
>>
>> Algorithms that implicitly detect sharing cannot
>> do much? Since we only need to find a first cycle?
>> Also a challenge to bring the association list to
>> native and lets say turn it into a hash table,
>>
>> don't know yet when and how even somebody would
>> attempt that. Big advantage of anything not using
>> Deutsch-Schorr-Waite , no write operation into the
>> given term. Write operation are sometimes
>>
>> poison for the CPU and the RAM.
>>
>> Bye
>>
>> Mild Shock schrieb:
>>> Hi,
>>>
>>> Assume that we live in a world where we
>>> have excess memory. So we can afford stacks!
>>> And then make the crucial observation,
>>>
>>> we can use the stack of the Prolog engine,
>>> no need to create an artificial stack in C,
>>> or use the native stack of C.
>>>
>>> I guess SWI-Prolog has already groked the
>>> first we can "afford stacks". But did anybody
>>> already grok the "100% Prolog" idea?
>>>
>>> Well we are not yet there 100% Prolog
>>> has still an overhead. Here is a little
>>> test acyclic_term/2:
>>>
>>> /* SWI-Prolog 9.3.26, C Stacks and/or Agendas */
>>> ?- time((between(1,30,_), acyclic2, fail; true)).
>>> % 330,150 inferences, 0.016 CPU in 0.023 seconds
>>> (69% CPU, 21129600 Lips)
>>> true.
>>>
>>> /* Trealla Prolog 2.79.6, ?? */
>>> ?- time((between(1,30,_), acyclic2, fail; true)).
>>> % Time elapsed 0.063s, 643413 Inferences, 10.166 MLips
>>>     true.
>>>
>>> /* Dogelog Player 1.3.5, 100% Prolog */
>>> ?- time((between(1,30,_), acyclic2, fail; true)).
>>> % Zeit 115 ms, GC 0 ms, Lips 11803904, Uhr 28.07.2025 10:03
>>> true.
>>>
>>> /* Scryer Prolog 0.9.4-417, Deutsch-Schorr-Waite  */
>>> ?- time((between(1,30,_), acyclic2, fail; true)).
>>> % CPU time: 0.130s, 626_829 inferences
>>> true.
>>>
>>> Bye
>>
> 

[toc] | [prev] | [next] | [standalone]

#639383 — Re: The End of Deutsch-Schorr-Waite [cycle_detection.rs] (Re: Novacore goes Bisimulation: Scryer Prolog is Slow!)

Mild Shock wrote:

> Hi,
> 
> Assume that we live in a world where we have excess memory. So we can
> afford stacks! And then make the crucial observation,
> 
> we can use the stack of the Prolog engine,
> no need to create an artificial stack in C,
> or use the native stack of C.
> 
> I guess SWI-Prolog has already groked the first we can "afford stacks".
> But did anybody already grok the "100% Prolog" idea?
> 
> Well we are not yet there 100% Prolog has still an overhead. Here is a
> little test acyclic_term/2:
> 
> /* SWI-Prolog 9.3.26, C Stacks and/or Agendas */ ?-
> time((between(1,30,_), acyclic2, fail; true)).
> % 330,150 inferences, 0.016 CPU in 0.023 seconds (69% CPU, 21129600
> Lips) true.

you assume too much. The 'overheat' is merely based on the size of memory 
required, and the number of instructions sent to the CPU's decoder, 
together with data, occupying the bus, through the pipeline, ignoring the 
pipeline etc. Not directly related to time. And 'stacks' ARE memory, not 
something to 'afford as excess' fucking stoopid.

[toc] | [prev] | [next] | [standalone]

#639384 — I guess your brain was "overheating" (Re: The End of Deutsch-Schorr-Waite [cycle_detection.rs])

I guess your brain was "overheating".

LoL

The problem of L1, L2, L3, cache trashing through
writes,  is not overheating, but it gets awfully slow,
creating an overhead not overheating.

Cache trashing (or cache thrashing) in the context
of L1, L2, and L3 CPU caches is a performance issue,
not a thermal one.

Jordon Molokovsky schrieb:
> Mild Shock wrote:
> 
>> Hi,
>>
>> Assume that we live in a world where we have excess memory. So we can
>> afford stacks! And then make the crucial observation,
>>
>> we can use the stack of the Prolog engine,
>> no need to create an artificial stack in C,
>> or use the native stack of C.
>>
>> I guess SWI-Prolog has already groked the first we can "afford stacks".
>> But did anybody already grok the "100% Prolog" idea?
>>
>> Well we are not yet there 100% Prolog has still an overhead. Here is a
>> little test acyclic_term/2:
>>
>> /* SWI-Prolog 9.3.26, C Stacks and/or Agendas */ ?-
>> time((between(1,30,_), acyclic2, fail; true)).
>> % 330,150 inferences, 0.016 CPU in 0.023 seconds (69% CPU, 21129600
>> Lips) true.
> 
> you assume too much. The 'overheat' is merely based on the size of memory
> required, and the number of instructions sent to the CPU's decoder,
> together with data, occupying the bus, through the pipeline, ignoring the
> pipeline etc. Not directly related to time. And 'stacks' ARE memory, not
> something to 'afford as excess' fucking stoopid.
> 

[toc] | [prev] | [next] | [standalone]

#639387 — Re: I guess your brain was "overheating" (Re: The End of Deutsch-Schorr-Waite [cycle_detection.rs])

Mild Shock wrote:

> The problem of L1, L2, L3, cache trashing through writes,  is not
> overheating, but it gets awfully slow,
> creating an overhead not overheating.

so fooling around needlessly in CPU's cache is not increasing the
temperature.. ; get yourself a proper education, before opening your
stupid mouth.

[toc] | [prev] | [next] | [standalone]

#639390 — The difference is only in one letter "t" or "d" (Was: I guess your brain was "overheating")

overheat:
https://en.wikipedia.org/wiki/Overheating_(electricity)

overhead:
https://en.wikipedia.org/wiki/Overhead_(computing)

Alton Grammatakakis schrieb:
> Mild Shock wrote:
> 
>> The problem of L1, L2, L3, cache trashing through writes,  is not
>> overheating, but it gets awfully slow,
>> creating an overhead not overheating.
> 
> so fooling around needlessly in CPU's cache is not increasing the
> temperature.. ; get yourself a proper education, before opening your
> stupid mouth.
> 

[toc] | [prev] | [next] | [standalone]

#639392 — Re: You literally wrote "overheat" (Re: I guess your brain was "overheating" (Re: The End of Deutsch-Schorr-Waite [cycle_detection.rs])

Mild Shock wrote:


> You literally wrote "overheat" here:
> 
> Jordon Molokovsky schrieb:
>  > you assume too much. The 'overheat' is merely based on the size of
>  > memory required, and the number of instructions sent to the CPU's
>  > decoder, together with data, occupying the bus, through the pipeline,
>  > ignoring the pipeline etc. Not directly related to time. And 'stacks'
>  > ARE memory, not something to 'afford as excess' fucking stoopid.

sense the punctuation, cretin, that's not overheating, then fucking around 
like stupid in CPU is overheating. Educate yourself civilized maner, 
idiot.

[toc] | [prev] | [next] | [standalone]

#639393 — Don't put large memory in your computer it might "overheat" (Re: You literally wrote "overheat")

Hi,

Yeah don't do this things:
- Don't overclock you CPU if system has poor airflow
- Do not use PC as a ram server rack, power supply not designed for it
- Refrain from usings computers alltogether, you seem to be a moron.

LoL

Bye

Jordon Molokovsky schrieb:
 > you assume too much. The 'overheat' is merely based on the size of
 > memory required, and the number of instructions sent to the CPU's
 > decoder, together with data, occupying the bus, through the pipeline,
 > ignoring the pipeline etc. Not directly related to time. And 'stacks'
 > ARE memory, not something to 'afford as excess' fucking stoopid.

[toc] | [prev] | [next] | [standalone]

#639394 — Re: Don't put large memory in your computer it might "overheat" (Was: You literally wrote "overheat")

Mild Shock wrote:

> Hi,
> 
> Yeah don't do this things:
> - Don't overclock you CPU if system has poor airflow - Do not use PC as
> a ram server rack, power supply not designed for it - Refrain from
> usings computers alltogether, you seem to be a moron. LoL Bye

you stupid polak kike just proved your imbecility in computers and 
related, not knowing what you do. Get yourself a proper education, you 
stupid fraud wannabe scientist.

> Jordon Molokovsky schrieb:
>  > you assume too much. The 'overheat' is merely based on the size of
>  > memory required, and the number of instructions sent to the CPU's
>  > decoder, together with data, occupying the bus, through the pipeline,
>  > ignoring the pipeline etc. Not directly related to time. And 'stacks'
>  > ARE memory, not something to 'afford as excess' fucking stoopid.

[toc] | [prev] | [next] | [standalone]

#639395 — Why Russ Bots Again: Micro Penis? (Was: Don't put large memory in your computer it might "overheat" )

Hoi Luigi

Again problems with your micro penis?

Bye

Mizraim Zelenenkov schrieb:
> Mild Shock wrote:
> 
>> Hi,
>>
>> Yeah don't do this things:
>> - Don't overclock you CPU if system has poor airflow - Do not use PC as
>> a ram server rack, power supply not designed for it - Refrain from
>> usings computers alltogether, you seem to be a moron. LoL Bye
> 
> you stupid polak kike just proved your imbecility in computers and
> related, not knowing what you do. Get yourself a proper education, you
> stupid fraud wannabe scientist.
> 
>> Jordon Molokovsky schrieb:
>>   > you assume too much. The 'overheat' is merely based on the size of
>>   > memory required, and the number of instructions sent to the CPU's
>>   > decoder, together with data, occupying the bus, through the pipeline,
>>   > ignoring the pipeline etc. Not directly related to time. And 'stacks'
>>   > ARE memory, not something to 'afford as excess' fucking stoopid.

[toc] | [prev] | [next] | [standalone]

#639386 — Re: I guess your brain was "overheating" (Re: The End of Deutsch-Schorr-Waite [cycle_detection.rs])

Mild Shock wrote:

> I guess your brain was "overheating".
> 
> LoL
> 
> The problem of L1, L2, L3, cache trashing through writes,  is not
> overheating, but it gets awfully slow,
> creating an overhead not overheating.

yet the uneducated visiting professor imbecile, undrestanding nothing all 
areas in everything. Nobody said 'overheating', cant you read the 
punctuation, you lying piece of shit

[toc] | [prev] | [next] | [standalone]

#639391 — You literally wrote "overheat" (Was: I guess your brain was "overheating")

You literally wrote "overheat" here:

Jordon Molokovsky schrieb:
 > you assume too much. The 'overheat' is merely based
 > on the size of memory required, and the number of
 > instructions sent to the CPU's decoder, together with
 > data, occupying the bus, through the pipeline, ignoring the
 > pipeline etc. Not directly related to time. And 'stacks'
 > ARE memory, not something to 'afford as excess' fucking stoopid.

Maybe you russian bots should use a better ChatGPT translator?

Emile Paduchev schrieb:
> Mild Shock wrote:
> 
>> I guess your brain was "overheating".
>>
>> LoL
>>
>> The problem of L1, L2, L3, cache trashing through writes,  is not
>> overheating, but it gets awfully slow,
>> creating an overhead not overheating.
> 
> yet the uneducated visiting professor imbecile, undrestanding nothing all
> areas in everything. Nobody said 'overheating', cant you read the
> punctuation, you lying piece of shit
> 

[toc] | [prev] | [next] | [standalone]

#639732 — Entering the Age of Rational Trees (2025) (Re: The End of Deutsch-Schorr-Waite [cycle_detection.rs])

 > I like your vibe, clearing the mind of
 > everything existing has a touch of a mystic
 > human being living an eremitic solitary
 > vocation on a far out mountain top.

It is not accidential that there is a resemblage
to the ivory tower of academics. Which might create
incestual orthodoxical knowledge, with very less value.

Prolog systems development is especially susceptible
to this fallacy, since it has a long tradition
going always the same paths, like WAM, etc.. etc..

The pointer swizzling algorithms of SWI-Prolog,
in connection with cyclic terms are a little
problematic. What if a Prolog term sits in a

read-only memory, or is shared among multiple threads.
How do you do pointer swizzling of ROM and not RAM?
We might indeed see the The End of Deutsch-Schorr-Waite,

although it made it still into Scryer Prolog:

 > **cycle_detection.rs**
Use the pointer reversal technique of the Deutsch-Schorr-
Waite algorithm to detect cycles in Prolog terms.
https://github.com/mthom/scryer-prolog/blob/master/src/machine/cycle_detection.rs

To enter the age of rational trees, it is probably
advisable to arm oneself not only with Fuzzy Testing,
but unlike the dislike of @kuniaki.mukai , one needs

to probably also study all the goodies from 1970's
computer science. But add a salt of scepticism, since
hardware and programming languages look different now.

Its not ALGOL anymore.

Mild Shock schrieb:
> Hi,
> 
> Assume that we live in a world where we
> have excess memory. So we can afford stacks!
> And then make the crucial observation,
> 
> we can use the stack of the Prolog engine,
> no need to create an artificial stack in C,
> or use the native stack of C.
> 
> I guess SWI-Prolog has already groked the
> first we can "afford stacks". But did anybody
> already grok the "100% Prolog" idea?
> 
> Well we are not yet there 100% Prolog
> has still an overhead. Here is a little
> test acyclic_term/2:
> 
> /* SWI-Prolog 9.3.26, C Stacks and/or Agendas */
> ?- time((between(1,30,_), acyclic2, fail; true)).
> % 330,150 inferences, 0.016 CPU in 0.023 seconds
> (69% CPU, 21129600 Lips)
> true.
> 
> /* Trealla Prolog 2.79.6, ?? */
> ?- time((between(1,30,_), acyclic2, fail; true)).
> % Time elapsed 0.063s, 643413 Inferences, 10.166 MLips
>     true.
> 
> /* Dogelog Player 1.3.5, 100% Prolog */
> ?- time((between(1,30,_), acyclic2, fail; true)).
> % Zeit 115 ms, GC 0 ms, Lips 11803904, Uhr 28.07.2025 10:03
> true.
> 
> /* Scryer Prolog 0.9.4-417, Deutsch-Schorr-Waite  */
> ?- time((between(1,30,_), acyclic2, fail; true)).
> % CPU time: 0.130s, 626_829 inferences
> true.
> 
> Bye

[toc] | [prev] | [next] | [standalone]

#639396 — The pairs are nasty, otherwise not always slow! (Re: Novacore goes Bisimulation: Scryer Prolog is Slow!)

Hi,

Looks like the pairs are really nasty.
I have them on the Novacore GIT.

This one is no problem for Scryer-Prolog:

test :-
    share(X), share(Y), X == Y.

/* SWI-Prolog 9.3.26 */
?- time(test).
% 32,140 inferences, 0.000 CPU in 0.002 seconds (0% CPU, Infinite Lips)
true.

/* Scryer Prolog 0.9.4-417 */
?- time(test).
    % CPU time: 0.006s, 32_042 inferences
    true.

/* Trealla Prolog 2.79.6 */
?- time(test).
% Time elapsed 0.016s, 42012 Inferences, 2.582 MLips
    true.

/* Dogelog Player 1.3.5 */
?- time(test2).
% % Zeit 83 ms, GC 0 ms, Lips 12117469, Uhr 30.07.2025 05:47
% true.

The Dogelog Player solutions uses a variant
of library(hash), called library(maps).
But hash tables are itself 100% Prolog.

Bye

Mild Shock schrieb:
> Hi,
> 
> Having fun with Bisimulation, and a new test
> suite of nasty circular pairs. But how store
> circular pairs, if clauses do not support
> 
> circular terms. Well chop it up into equations,
> I create 1000 such equation pairs:
> 
> test([A = c(A, B), C = c(A, D), E = n, _ = c(F, B),
>        F = c(C, C), G = c(G, D), D = c(E, C), B = n],
>       [H = c(H, I), J = c(K, I), L = c(L, I), I = c(M, N),
>        O = c(K, J), N = n, K = c(K, J), M = c(K, O)]).
> Etc..
> 
> The pairs are nasty because the usual compare_with_stack/2
> chokes on them. Here some results:
> 
> /* SWI-Prolog 9.3.26 */
> ?- time((between(1,30,_), part, fail; true)).
> % 540,118 inferences, 0.047 CPU in 0.041 seconds (115% CPU, 11522517 Lips)
> true.
> 
> /* Trealla Prolog 2.78.40 */
> ?- time((between(1,30,_), part, fail; true)).
> % Time elapsed 0.113s, 1143903 Inferences, 10.157 MLips
>     true.
> 
> /* Scryer Prolog 0.9.4-417 */
> ?- time((between(1,30,_), part, fail; true)).
>     % CPU time: 0.226s, 1_117_809 inferences
>     true.
> 
> /* Dogelog Player 1.3.5 */
> ?- time((between(1,30,_), part2, fail; true)).
> % Zeit 309 ms, GC 0 ms, Lips 8693718, Uhr 25.07.2025 13:47
> true.
> 
> The amazing thing is, I compared a 100% Prolog
> implementation, so there is a lot of head room
> for improvement:
> 
> part2 :-
>     bitest(X,Y), X ~~ Y, fail; true.
> 
> The operator (~~)/2 is part of library(math),
> and has been implemented with same_term/2 so far.
> 
> Bye

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | sci.math

csiph-web