Search code examples
memory-managementprologswi-prologgnu-prolog

why does gprolog need so much RAM?

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!

Solution

  • 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.