findall/3 bagof/3 performance about trealla HOT 11 CLOSED

To get it right and slightly better, the (sub-)bagof/3 just need to 'ignore' B^ instead of X^
... bagof(Y,B^(between(1,3,B),X),Z) ...

?- testbb,nl.
Time elapsed 24.9s
1500000 bagof/bagof Elements
true.
?-

from trealla.

Comparsion

Swipl:

bagof/3

?- testbb.
% ... 3.248 seconds ... % bagof/3 very fast.
1500000 bagof/bagof Elements


/************/

Aged B-Prolog:

findall/3

| ?- testff.
CPU time 4.165 seconds.
1500000 findall/findall Elements

| ?- testff.  % Run again
CPU time 0.621 seconds.  % Now the winner, 3 times faster than Swipl (1.768 seconds)
1500000 findall/findall Elements

bagof/3 

| ?- testbb.
CPU time 22.878 seconds. % Like Trealla
1500000 bagof/bagof Elements

| ?- testbb. % Run again
CPU time 18.165 seconds.  % Again, faster now(4 secs). Trealla and Swipl do not show this effect
1500000 bagof/bagof Elements

from trealla.

Well bagof/3 emulating findall/3 (by full existential quantification) will always be an order of magnitude slower.

from trealla.

Nice of bagof/3 is that you can have a result like this:
[[2,3,4],[3,4,5],[4,5,6],[5,6,7],[6,7,8]] % 27sec
or like so:
[[2],[3],[4],[3],[4],[5],[4],[5],[6],[5],[6],[7],[6],[7],[8]] % 39sec
Whereby this output takes 12secs more:
Time elapsed 39s
4500000 bagof/bagof Elements

from trealla.

Now you might say...yeah there are now 4500000 lists in the list and slower again.

B-Prolog goes in the other direction:
CPU time 10.563 seconds.
4500000 bagof/bagof Elements

Lol,Now how many elements must be in the list to reach 0.0s?

Seriously, I wonder how clever B-Prolog is. Even Swipl can't match up:

swipl
?- testbb_15.
... 3.261 seconds ...
1500000 bagof/bagof Elements % [[2,3,4],[3,4,5],[4,5,6], ... ]
?- testbb_45.
... 7.073 seconds ...
4500000 bagof/bagof Elements % [[2],[3],[4],[3],[4],[5],[4],[5],[6], ... ] Time increased (doubled)

b-prolog
| ?- testbb_15.
CPU time 18.162 seconds.
1500000 bagof/bagof Elements % [[2,3,4],[3,4,5],[4,5,6], ... ]

| ?- testbb_45.
CPU time 10.542 seconds.
4500000 bagof/bagof Elements % [[2],[3],[4],[3],[4],[5],[4],[5],[6], ... ] Time decreased (halved)

from trealla.

Performance Test Summary
________________________


SWI (perhaps a native one).
1.81s  1500000 findall/findall
3.35s  1500000 bagof/bagof
7.04s  4500000 bagof/bagof


Systems using the RoK version:

B-Prolog (setof.pl by Richard O’Keefe, Garbage collector off).
0.63s  1500000 findall/findall
1.71s  1500000 bagof/bagof
2.48s  4500000 bagof/bagof

Trealla (RoK)
 2.7s   1500000 findall/findall
25.9s   1500000 bagof/bagof
40.1s   4500000 bagof/bagof

_________________________

It is a terrible Warning.
How could it be that a system dated from 2014 beats everything?
(This beats me, too)

from trealla.

from trealla.

GC on:
0.619s 1500000 findall/findall
2.126s 1500000 bagof/bagof
6.695s 4500000 bagof/bagof % !!

Cycle check
It is an iterative performance test.
There is a predicate called acyclic term(Term): This fails if Term is cyclic
but I don't get it where and why to use it.
Anyway, good hint.
Perhaps it is possible to turn off Trealla's and SWI's cycle checking, to be fair?

SWI gc off (a bit faster)
?- set_prolog_flag(gc, false).
1.926s 1500000 findall/findall % not this
2.396s 1500000 bagof/bagof % but this
5.429s 4500000 bagof/bagof % and this

And now? Well, THE not so unusual next bad suspicion:
?- testbb.
:
?- testbb.
:
?- testbb.
ERROR: Stack limit (1.0Gb) exceeded

As long as people do not include "The role that memory can really play(in C programming for applications)",
we see these errors again and again(resource errors, core dumps)
(swipl-) GC off is useless!
testbb/0 is a "standalone" predicate and things should be reset after completed!
What has this "?- query." to do with the next "?- query."
B-Prolog: There is no such negative impact (whether gc is on or off).

NOTE:

$ swipl --version
SWI-Prolog version 8.4.0 for x86_64-linux

It could be that such issues are fixed in the meantime,
but I do not follow overloaded, bloated systems any longer:
swipl-devel repository uses many many Git submodules.
scryer-prolog soaks in over 300 crates/libs from everywhere?
I say: "Wow!", Frank Zappa says: "Sick!"

from trealla.

from trealla.

I didn't say its outdated but dated (from 2014) and I've read it went into the core of picat-lang.org.
The (picat) source code is available but I can't find the original bp source.

B-Prolog (Issue #30)

| ?- time(testmem(500000)). five-hundred-thousand elems (in quintuplicate)
500000
500000
500000
500000
500000

CPU time 0.971 seconds.

| ?- time(testmem(5000000)). five-million elems
5000000
5000000
5000000
5000000
5000000

CPU time 10.41 seconds.

from trealla.

from trealla.