why does gprolog need so much RAM?

Question

The following is from top command:

                            size  res 
1127 ***       1  20    0   117M  2196K ttyin   0   0:00  0.00% gprolog

1149 ***       1  23    0 10700K  3728K ttyin   0   0:00  0.00% swipl

Its RES is reasonable but its size is too big compared with swipl .

The OS is freebsd 9.0.

Sincerely!

Answer 1

In your ps/top-listing there are two numbers: The virtual memory allocated (size) and the physical memory that is actually in use (res). From this it seems that GNU Prolog initially uses less memory than SWI. That is: 2196K for GNU versus 3728K for SWI.

But you cannot conclude anything of relevance from these numbers alone. The only thing you can say is that the default-environment with the toplevel needs so much memory to start up — provided you have not "paged out" the processes with another program...

Both systems try to keep memory consumption low, but on different levels:

GNU Prolog offers compilation to stand-alone executables that skip unused built-in predicates. The executable code is treated similarly to C: It is thus read-only mapped into physical memory. If you run several instances of such an executable, they all will share the same physical memory for the executables.

On the downside, GNU Prolog lacks garbage collection. Both for the heap (copystack) and for atoms (symboltable). To avoid overflow handling, memory areas are allocated generously. But this is only a reservation for virtual memory. As far as I know all current Unix variations over-commit virtual memory so this does not take away the corresponding swap-space.

SWI-Prolog on the other hand allocates its Prolog code in writeable memory. Further that memory is "touched" (marked/unmarked) during GC. As a consequence Prolog programs cannot be shared between different SWI instances, not even with dynamic re-sharing like mergemem. That is, mergemem (or similar) can page-share it, but upon the next db-GC it is copy-on-write unshared. See the link how sharing can reduce memory consumption for SICStus. But then SWI has multithread-support which somewhat induces sharing.

SWI boasts one of the very best and complete garbage collectors for the heap and atoms.

So, your mileage may vary. There is no doubt that best would be a system which unites the advantages of both.

Answer 2

gprolog mmaps all stacks (whose size are controlled via environment variables). The default values are 16MB for the trail, the constraint and the local stack + 32MB for the heap. There is also the atom table (also controlled via an environment variable). Defaults values are high to work in most cases. NB: since this is virtual memory (via mmap) it is only physically allocated when needed. So it is not really a problem to allocate large amount of memory (well the swap should be enough for the max required memory however). Anyway, you can redefine them (for instance if you don't use the FD solver you can set the CSTRSZ env var to 0).

SWI Prolog dynamically increases (and decreases I suppose) the size of its internal stacks when needed. So at start very few memory is required.