There are two approaches to garbage collection
in Prolog systems right now:

- We dont have garbage collection:
Ehm, oh, we didn't have time to implement garbage
collection. We were up to our nose in the mud of
implementing built-ins and get top-level/consult running.

- We have garbage collection, but we don't tell you its achilles heel:
Yeah, we have garbage collection. And we can show
you some hand picked benchmark. And everything looks
brilliantly fine, implying we are better than those without.

So what will be the task for 2022. Well do some
better testing!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For example Peano factorial has two binary rules. The Peano
factorial example is also heavy on term creation, since it
creates very long Peano numbers, actually in the n-the

solution a term of size n!. So it puts quite some pressure
on any garbage collection.

Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:39:50 UTC+2:

For example this test case seems to test anything else
than garbage collection. Mostlikely it only tests term/variable representation size and a litte garbage collection:

Out of memory with meta-interpreter #281 https://github.com/infradig/trealla/issues/281#issuecomment-950251166

Concerning SWI-Prolog, try an example that fills the local stack.
The above has no binary rules , i.e. clauses with two goals. There
is one, but the first goal is a fact, so its still not really binary.

Try in SWI-Prolog an example with binary recursion, and where
you don’t reach the end of the clauses so early. Also despite the seemingly complex look of the example, there seems to be not

much term construction going on, it rather looks to me that most
of it is unification based term destruction which usually does
not create so much garbage.
Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:14:29 UTC+2:

There are two approaches to garbage collection
in Prolog systems right now:

- We dont have garbage collection:
Ehm, oh, we didn't have time to implement garbage
collection. We were up to our nose in the mud of
implementing built-ins and get top-level/consult running.

- We have garbage collection, but we don't tell you its achilles heel: Yeah, we have garbage collection. And we can show
you some hand picked benchmark. And everything looks
brilliantly fine, implying we are better than those without.

So what will be the task for 2022. Well do some
better testing!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

For example this test case seems to test anything else
than garbage collection. Mostlikely it only tests term/variable
representation size and a litte garbage collection:

Out of memory with meta-interpreter #281 https://github.com/infradig/trealla/issues/281#issuecomment-950251166

Concerning SWI-Prolog, try an example that fills the local stack.
The above has no binary rules , i.e. clauses with two goals. There
is one, but the first goal is a fact, so its still not really binary.

Try in SWI-Prolog an example with binary recursion, and where
you don’t reach the end of the clauses so early. Also despite the
seemingly complex look of the example, there seems to be not

much term construction going on, it rather looks to me that most
of it is unification based term destruction which usually does
not create so much garbage.

Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:14:29 UTC+2:

There are two approaches to garbage collection
in Prolog systems right now:

- We dont have garbage collection:
Ehm, oh, we didn't have time to implement garbage
collection. We were up to our nose in the mud of
implementing built-ins and get top-level/consult running.

- We have garbage collection, but we don't tell you its achilles heel:
Yeah, we have garbage collection. And we can show
you some hand picked benchmark. And everything looks
brilliantly fine, implying we are better than those without.

So what will be the task for 2022. Well do some
better testing!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Currently I am having fun with an AMD Ryzen. The benchmarks
I am running are all on GitHub. I tested single threaded:

- Core Test https://github.com/jburse/jekejeke-samples/tree/master/jekrun_bench/core

- Occurs Check Test https://github.com/jburse/jekejeke-samples/tree/master/jekrun_bench/occurs

- CLP(FD) Test https://github.com/jburse/jekejeke-samples/tree/master/jekmin_bench/clpfd

- CLP(B) Test https://github.com/jburse/jekejeke-samples/tree/master/jekmin_bench/clpb

It turns out that there is something strange going on. In constraint programming Jekejeke is more Ryzen friendly.

Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:41:46 UTC+2:

For example Peano factorial has two binary rules. The Peano
factorial example is also heavy on term creation, since it
creates very long Peano numbers, actually in the n-the

solution a term of size n!. So it puts quite some pressure
on any garbage collection.
Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:39:50 UTC+2:

For example this test case seems to test anything else
than garbage collection. Mostlikely it only tests term/variable representation size and a litte garbage collection:

Out of memory with meta-interpreter #281 https://github.com/infradig/trealla/issues/281#issuecomment-950251166

Concerning SWI-Prolog, try an example that fills the local stack.
The above has no binary rules , i.e. clauses with two goals. There
is one, but the first goal is a fact, so its still not really binary.

Try in SWI-Prolog an example with binary recursion, and where
you don’t reach the end of the clauses so early. Also despite the seemingly complex look of the example, there seems to be not

much term construction going on, it rather looks to me that most
of it is unification based term destruction which usually does
not create so much garbage.
Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:14:29 UTC+2:

There are two approaches to garbage collection
in Prolog systems right now:

- We dont have garbage collection:
Ehm, oh, we didn't have time to implement garbage
collection. We were up to our nose in the mud of
implementing built-ins and get top-level/consult running.

- We have garbage collection, but we don't tell you its achilles heel: Yeah, we have garbage collection. And we can show
you some hand picked benchmark. And everything looks
brilliantly fine, implying we are better than those without.

So what will be the task for 2022. Well do some
better testing!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Datawise I got this strange thingy, smaller percentage is better:

core occurs clpfd clpb
jekejeke 89% 92% 81% 85%
swi 82% 82% 85% 90%

The test results are seen graphically here:

Intel Skylake vs AMD Ryzen the Prolog Battle (Jekejeke) https://twitter.com/dogelogch/status/1453693429758713856

Intel Skylake vs AMD Ryzen the Prolog Battle (Jekejeke) https://www.facebook.com/groups/dogelog

We are now planning to make a real multi-threading test as well. We
have multi-threading benchmarks, but we need to massage them a little
before we can provide results. This will possibly provide more valuable insights.

Mostowski Collapse schrieb am Donnerstag, 28. Oktober 2021 um 14:08:16 UTC+2:

Currently I am having fun with an AMD Ryzen. The benchmarks
I am running are all on GitHub. I tested single threaded:

- Core Test https://github.com/jburse/jekejeke-samples/tree/master/jekrun_bench/core

- Occurs Check Test https://github.com/jburse/jekejeke-samples/tree/master/jekrun_bench/occurs

- CLP(FD) Test https://github.com/jburse/jekejeke-samples/tree/master/jekmin_bench/clpfd

- CLP(B) Test https://github.com/jburse/jekejeke-samples/tree/master/jekmin_bench/clpb

It turns out that there is something strange going on. In constraint programming Jekejeke is more Ryzen friendly.
Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:41:46 UTC+2:

For example Peano factorial has two binary rules. The Peano
factorial example is also heavy on term creation, since it
creates very long Peano numbers, actually in the n-the

solution a term of size n!. So it puts quite some pressure
on any garbage collection.
Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:39:50 UTC+2:

For example this test case seems to test anything else
than garbage collection. Mostlikely it only tests term/variable representation size and a litte garbage collection:

Out of memory with meta-interpreter #281 https://github.com/infradig/trealla/issues/281#issuecomment-950251166

Concerning SWI-Prolog, try an example that fills the local stack.
The above has no binary rules , i.e. clauses with two goals. There
is one, but the first goal is a fact, so its still not really binary.

Try in SWI-Prolog an example with binary recursion, and where
you don’t reach the end of the clauses so early. Also despite the seemingly complex look of the example, there seems to be not

much term construction going on, it rather looks to me that most
of it is unification based term destruction which usually does
not create so much garbage.
Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:14:29 UTC+2:

There are two approaches to garbage collection
in Prolog systems right now:

- We dont have garbage collection:
Ehm, oh, we didn't have time to implement garbage
collection. We were up to our nose in the mud of
implementing built-ins and get top-level/consult running.

- We have garbage collection, but we don't tell you its achilles heel: Yeah, we have garbage collection. And we can show
you some hand picked benchmark. And everything looks
brilliantly fine, implying we are better than those without.

So what will be the task for 2022. Well do some
better testing!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Actually I wanted first to test something else, a Windows
Surface with a hybrid architecture. But it was out of shelf.

Anyway my 10nm SuperFin testing is already outdated,
since Alder Lake is on the horizon, and it is a hybrid architecture!

https://en.wikipedia.org/wiki/Alder_Lake_%28microprocessor%29

https://en.wikipedia.org/wiki/Heterogeneous_computing

Interesting. Maybe can complete my initial testing idea
by getting hold of such a new machine?

Mostowski Collapse schrieb am Mittwoch, 10. November 2021 um 23:56:34 UTC+1:

We also tested a new machine built with 10nm SuperFin.
The speed-up is impressive, 65% and not only 85%:

Intel Skylake vs Generation 11 the Prolog Battle (Jekejeke) https://twitter.com/dogelogch/status/1458021043910717444

But again only a single threaded test. Stay tuned
for upcoming multi threaded tests.
Mostowski Collapse schrieb am Donnerstag, 28. Oktober 2021 um 14:10:03 UTC+2:

Datawise I got this strange thingy, smaller percentage is better:

core occurs clpfd clpb
jekejeke 89% 92% 81% 85%
swi 82% 82% 85% 90%

The test results are seen graphically here:

Intel Skylake vs AMD Ryzen the Prolog Battle (Jekejeke) https://twitter.com/dogelogch/status/1453693429758713856

Intel Skylake vs AMD Ryzen the Prolog Battle (Jekejeke) https://www.facebook.com/groups/dogelog

We are now planning to make a real multi-threading test as well. We
have multi-threading benchmarks, but we need to massage them a little before we can provide results. This will possibly provide more valuable insights.
Mostowski Collapse schrieb am Donnerstag, 28. Oktober 2021 um 14:08:16 UTC+2:

Currently I am having fun with an AMD Ryzen. The benchmarks
I am running are all on GitHub. I tested single threaded:

- Core Test https://github.com/jburse/jekejeke-samples/tree/master/jekrun_bench/core

- Occurs Check Test https://github.com/jburse/jekejeke-samples/tree/master/jekrun_bench/occurs

- CLP(FD) Test https://github.com/jburse/jekejeke-samples/tree/master/jekmin_bench/clpfd

- CLP(B) Test https://github.com/jburse/jekejeke-samples/tree/master/jekmin_bench/clpb

It turns out that there is something strange going on. In constraint programming Jekejeke is more Ryzen friendly.
Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:41:46 UTC+2:

For example Peano factorial has two binary rules. The Peano
factorial example is also heavy on term creation, since it
creates very long Peano numbers, actually in the n-the

solution a term of size n!. So it puts quite some pressure
on any garbage collection.
Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:39:50 UTC+2:

For example this test case seems to test anything else
than garbage collection. Mostlikely it only tests term/variable representation size and a litte garbage collection:

Out of memory with meta-interpreter #281 https://github.com/infradig/trealla/issues/281#issuecomment-950251166

Concerning SWI-Prolog, try an example that fills the local stack. The above has no binary rules , i.e. clauses with two goals. There is one, but the first goal is a fact, so its still not really binary.

Try in SWI-Prolog an example with binary recursion, and where
you don’t reach the end of the clauses so early. Also despite the seemingly complex look of the example, there seems to be not

much term construction going on, it rather looks to me that most
of it is unification based term destruction which usually does
not create so much garbage.
Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:14:29 UTC+2:

There are two approaches to garbage collection
in Prolog systems right now:

- We dont have garbage collection:
Ehm, oh, we didn't have time to implement garbage
collection. We were up to our nose in the mud of
implementing built-ins and get top-level/consult running.

- We have garbage collection, but we don't tell you its achilles heel:
Yeah, we have garbage collection. And we can show
you some hand picked benchmark. And everything looks
brilliantly fine, implying we are better than those without.

So what will be the task for 2022. Well do some
better testing!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

We also tested a new machine built with 10nm SuperFin.
The speed-up is impressive, 65% and not only 85%:

Intel Skylake vs Generation 11 the Prolog Battle (Jekejeke) https://twitter.com/dogelogch/status/1458021043910717444

But again only a single threaded test. Stay tuned
for upcoming multi threaded tests.

Mostowski Collapse schrieb am Donnerstag, 28. Oktober 2021 um 14:10:03 UTC+2:

Datawise I got this strange thingy, smaller percentage is better:

core occurs clpfd clpb
jekejeke 89% 92% 81% 85%
swi 82% 82% 85% 90%

The test results are seen graphically here:

Intel Skylake vs AMD Ryzen the Prolog Battle (Jekejeke) https://twitter.com/dogelogch/status/1453693429758713856

Intel Skylake vs AMD Ryzen the Prolog Battle (Jekejeke) https://www.facebook.com/groups/dogelog

We are now planning to make a real multi-threading test as well. We
have multi-threading benchmarks, but we need to massage them a little
before we can provide results. This will possibly provide more valuable insights.
Mostowski Collapse schrieb am Donnerstag, 28. Oktober 2021 um 14:08:16 UTC+2:

Currently I am having fun with an AMD Ryzen. The benchmarks
I am running are all on GitHub. I tested single threaded:

- Core Test https://github.com/jburse/jekejeke-samples/tree/master/jekrun_bench/core

- Occurs Check Test https://github.com/jburse/jekejeke-samples/tree/master/jekrun_bench/occurs

- CLP(FD) Test https://github.com/jburse/jekejeke-samples/tree/master/jekmin_bench/clpfd

- CLP(B) Test https://github.com/jburse/jekejeke-samples/tree/master/jekmin_bench/clpb

It turns out that there is something strange going on. In constraint programming Jekejeke is more Ryzen friendly.
Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:41:46 UTC+2:

For example Peano factorial has two binary rules. The Peano
factorial example is also heavy on term creation, since it
creates very long Peano numbers, actually in the n-the

solution a term of size n!. So it puts quite some pressure
on any garbage collection.
Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:39:50 UTC+2:

For example this test case seems to test anything else
than garbage collection. Mostlikely it only tests term/variable representation size and a litte garbage collection:

Out of memory with meta-interpreter #281 https://github.com/infradig/trealla/issues/281#issuecomment-950251166

Concerning SWI-Prolog, try an example that fills the local stack.
The above has no binary rules , i.e. clauses with two goals. There
is one, but the first goal is a fact, so its still not really binary.

Try in SWI-Prolog an example with binary recursion, and where
you don’t reach the end of the clauses so early. Also despite the seemingly complex look of the example, there seems to be not

much term construction going on, it rather looks to me that most
of it is unification based term destruction which usually does
not create so much garbage.
Mostowski Collapse schrieb am Dienstag, 26. Oktober 2021 um 15:14:29 UTC+2:

There are two approaches to garbage collection
in Prolog systems right now:

- We dont have garbage collection:
Ehm, oh, we didn't have time to implement garbage
collection. We were up to our nose in the mud of
implementing built-ins and get top-level/consult running.

- We have garbage collection, but we don't tell you its achilles heel:
Yeah, we have garbage collection. And we can show
you some hand picked benchmark. And everything looks
brilliantly fine, implying we are better than those without.

So what will be the task for 2022. Well do some
better testing!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)