以下はトップコマンドからのものです：
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
そのRESは妥当ですが、そのサイズはswiplと比較して大きすぎます。
OSはfreebsd9.0です。
心から！
ps / top-listingには、割り当てられた仮想メモリ（size）と実際に使用されている物理メモリ（res）の2つの数値があります。このことから、GNUPrologは最初はSWIよりも少ないメモリを使用しているようです。つまり、GNUの場合は2196K、SWIの場合は3728Kです。
しかし、これらの数字だけから関連性のあるものを結論付けることはできません。あなたが言うことができる唯一のことは、トップレベルのデフォルト環境は起動するのに非常に多くのメモリを必要とするということです—あなたが別のプログラムでプロセスを「ページアウト」していなければ...
どちらのシステムもメモリ消費量を低く抑えようとしますが、レベルは異なります。
GNU Prologは、未使用の組み込み述語をスキップするスタンドアロン実行可能ファイルへのコンパイルを提供します。実行可能コードはCと同様に扱われます。したがって、物理メモリに読み取り専用でマップされます。このような実行可能ファイルの複数のインスタンスを実行すると、それらはすべて実行可能ファイルの同じ物理メモリを共有します。
欠点として、GNUPrologにはガベージコレクションがありません。ヒープ（コピースタック）とアトム（シンボル化可能）の両方。オーバーフロー処理を回避するために、メモリ領域は十分に割り当てられます。ただし、これは仮想メモリの予約にすぎません。私の知る限り、現在のすべてのUnixバリエーションは仮想メモリをオーバーコミットしているため、対応するスワップスペースが失われることはありません。
一方、SWI-Prologは、そのPrologコードを書き込み可能なメモリに割り当てます。さらに、そのメモリは、GC中に「タッチ」（マーク/マークなし）されます。結果として、 mergememのような動的な再共有があっても、Prologプログラムを異なるSWIインスタンス間で共有することはできません。つまり、mergemem（または同様のもの）はページ共有できますが、次のdb-GCではコピーオンライト非共有になります。共有によってSICStusのメモリ消費をどのように削減できるかについてのリンクを参照してください。しかし、SWIにはマルチスレッドサポートがあり、共有をいくらか誘発します。
SWIは、ヒープとアトム用の最高かつ完全なガベージコレクターの1つを誇っています。
そのため、マイレージは異なる場合があります。両方のメリットを融合させたシステムが最適であることは間違いありません。
gprologすべてのスタックをmmapします（そのサイズは環境変数を介して制御されます）。デフォルト値は16MB for the trail、制約とローカルスタック+ 32MB for the heapです。アトムテーブルもあります（これも環境変数を介して制御されます）。ほとんどの場合、デフォルト値は高く機能します。注意：これは（mmapを介した）仮想メモリであるため、必要な場合にのみ物理的に割り当てられます。したがって、大量のメモリを割り当てることは実際には問題ではありません（ただし、必要な最大メモリに対してスワップで十分なはずです）。とにかく、それらを再定義できます（たとえば、FDソルバーを使用しない場合は、CSTRSZ env varを0に設定できます）。
SWI Prologは、必要に応じて内部スタックのサイズを動的に増加（および減少）します。したがって、開始時に必要なメモリはごくわずかです。