d34676@tansei.cc.u-tokyo.ac.jp (Akira Kurihara) (05/01/91)
I am porting a Common Lisp program from Macintosh Allegro Common
Lisp 1.3.2 (MACL) to Lucid Sun Common Lisp 3.0.1 (SunCL). Please give me
some suggestions!
Here is a description.
Suppose I have a function called my-function whose usage is
(my-function e) with an integer e >= 1. The source file of this
function is roughly 100 Kilobytes. The memory consumed by
(my-fucntion e) is roughly linear on e, i.e., of the form Ae+B.
The time consumed by (my-function e) is roughly C*3^e, with a
constant C. (my-function 12) took about 12 hours both on Macintosh SE
(accelarated with 25MHz 68020) with 4 Megabytes of memory and
on SparcStation IPC with 24 Megabytes of memory and with a lot of
hard disk storage. (my-function e) gave a correct answer for
1 <= e <= 13 on Macintosh and for 1 <= e <= 12 on Sun.
(Nothing has been calculated for e >= 14.)
However, (my-function 13) on Sun could not normally terminate because of
some memory problem.
This problem is that the Read-Write-Area increased and increased during
calculation. The segments for ephemeral gc (I think) disappeared and
the Dynamic-0(1)-Area descreased its size.
In fact, this problem is not only for e = 13, but this occured even
when e <= 12. For e <= 12, this problem occured but, because of the
sufficient memory, (my-function e) gave a correct answer.
(room t) reported the followings.
===== Report for (my-function 12) =====
Almost at the beginning,
;;; 12872 words [51488 bytes] of dynamic storage in use.
;;; 1297590 words [5190360 bytes] of free storage available before a GC.
;;; 2608052 words [10432208 bytes] of free storage available if GC is disabled.
;;; Semi-space Size: 5120K bytes [80 segments]
;;; Current Dynamic Area: Dynamic-1-Area
;;; GC Status: Enabled
;;; Reserved Free Space: 64K bytes [1 segment]
;;; Memory Growth Limit: 32768K bytes [512 segments], total
;;; Memory Growth Rate: 256K bytes [4 segments]
;;; Reclamation Ratio: 33% desired free after garbage collection
;;; Area Information:
;;; Name Size [used/allocated]
;;; ---- ----
;;; Ephemeral Level 2 0K/640K bytes, 0/10 segments
;;; Ephemeral Level 0 423K/448K bytes, 7/7 segments
;;; Ephemeral Even-level OSP 0K/576K bytes, 0/9 segments
;;; Ephemeral Level 1 130K/576K bytes, 3/9 segments
;;; Ephemeral Odd-level OSP 0K/448K bytes, 0/7 segments
;;; Foreign-Area 37K/128K bytes, 1/2 segments
;;; Dynamic-0-Area 0K/5120K bytes, 0/80 segments
;;; Dynamic-1-Area 51K/5119K bytes, 1/80 segments
;;; Static-Area 1448K/1472K bytes, 23/23 segments
;;; Read-Write-Area 3154K/3200K bytes, 50/50 segments
;;; Readonly-Pointer-Area 954K/960K bytes, 15/15 segments
;;; Readonly-Non-Pointer-Area 3987K/4032K bytes, 63/63 segments
Almost at the end,
;;; 47204 words [188816 bytes] of dynamic storage in use.
;;; 673434 words [2693736 bytes] of free storage available before a GC.
;;; 1394072 words [5576288 bytes] of free storage available if GC is disabled.
;;; Semi-space Size: 2816K bytes [44 segments]
;;; Current Dynamic Area: Dynamic-0-Area
;;; GC Status: Enabled
;;; Reserved Free Space: 192K bytes [3 segments]
;;; Memory Growth Limit: 32768K bytes [512 segments], total
;;; Memory Growth Rate: 256K bytes [4 segments]
;;; Reclamation Ratio: 33% desired free after garbage collection
;;; Area Information:
;;; Name Size [used/allocated]
;;; ---- ----
;;; Foreign-Area 37K/128K bytes, 1/2 segments
;;; Dynamic-0-Area 189K/2815K bytes, 3/44 segments
;;; Dynamic-1-Area 0K/2816K bytes, 0/44 segments
;;; Static-Area 1464K/1472K bytes, 23/23 segments
;;; Read-Write-Area 20354K/20414K bytes, 319/319 segments
;;; Readonly-Pointer-Area 954K/960K bytes, 15/15 segments
;;; Readonly-Non-Pointer-Area 3987K/4032K bytes, 63/63 segments
The size of Read-Write-Area is so large.
Ephemeral gc disappeared and the size of Dynamic-0(1)-Area decreased.
However, (my-function 12) returned the same answer as Macintosh
gave.
===== Report for (my-function 13) =====
At the beggining,
--- Almost the same as when e = 12
At several hours before abnormal termination,
;;; 46594 words [186376 bytes] of dynamic storage in use.
;;; 477436 words [1909744 bytes] of free storage available before a GC.
;;; 1001466 words [4005864 bytes] of free storage available if GC is disabled.
;;; Semi-space Size: 2048K bytes [32 segments]
;;; Current Dynamic Area: Dynamic-1-Area
;;; GC Status: Enabled
;;; Reserved Free Space: 192K bytes [3 segments]
;;; Memory Growth Limit: 32768K bytes [512 segments], total
;;; Memory Growth Rate: 256K bytes [4 segments]
;;; Reclamation Ratio: 33% desired free after garbage collection
;;; Area Information:
;;; Name Size [used/allocated]
;;; ---- ----
;;; Foreign-Area 37K/128K bytes, 1/2 segments
;;; Dynamic-0-Area 0K/2048K bytes, 0/32 segments
;;; Dynamic-1-Area 186K/2047K bytes, 3/32 segments
;;; Static-Area 1464K/1472K bytes, 23/23 segments
;;; Read-Write-Area 21937K/21950K bytes, 343/343 segments
;;; Readonly-Pointer-Area 954K/960K bytes, 15/15 segments
;;; Readonly-Non-Pointer-Area 3987K/4032K bytes, 63/63 segments
Finally at the termination--this is not a report of (room t)---,
;;; Expanding Reserved Memory
;;; GC: 47662 words [190648 bytes] of dynamic storage in use.
;;; 17872 words [71488 bytes] of free storage available before a GC.
;;; 83406 words [333624 bytes] of free storage available if GC is disabled.
Clearing input from *debug-io*
>>Error: Attempting to allocate 4 non-dynamic segments. In order to do so,
sufficient dynamic space must be reassigned that it may no longer be
possible to GC.
SYSTEM:GC-INTERNAL:
:C 0: Allocation will be allowed and the GC will be disabled.
:A 1: Abort to Lisp Top Level
->
===== end of Reports of (room t) =====
I already found some bugs in my program when porting from MACL to SunCL.
For example,
(make-array 3 :adjustable t)
returns the same results on both MACL and SunCL, while
(adjust-array (make-array 3 :adjustable t) 6)
returns different results. So I had to fix some. Of course, both
MACL and SunCL are compatible with Guy Steele's book.
In the my-function,
- no float is used.
- integers as big as 10^40 may appear.
- adjustable arrays are extensively used.
Summing up.
For (my-function e) for e <= 12, both MACL and SunCL returned
the same answer, while (my-function e) for e <= 12 on SunCL
potentially has such problem. And (my-function 13) on SunCL could
not normally terminate, while (my-function 13) on MACL returned a
(probably correct) answer.
How could I solve this problem? Please, give me some suggestions!
Thank you.
--
d34676@tansei.cc.u-tokyo.ac.jp
Akira Kurihara
School of Mathematics
Japan Women's University
Mejirodai 2-8-1, Bunkyo-ku
Tokyo 112
Japan
03-3943-3131 ext-7243barmar@think.com (Barry Margolin) (05/02/91)
In article <461@tansei1.tansei.cc.u-tokyo.ac.jp> d34676@tansei.cc.u-tokyo.ac.jp (Akira Kurihara) writes: >I am porting a Common Lisp program from Macintosh Allegro Common >Lisp 1.3.2 (MACL) to Lucid Sun Common Lisp 3.0.1 (SunCL). Please give me >some suggestions! I'm not sure how useful this suggestion will be: upgrade to version 4.0, and get the patch to bug 5648. I believe this bug refers to a whole bunch of problems reported in the Ephemeral GC. By the way, when you're estimating the memory use of your program, don't forget to count all the intermediate data. You mentioned that your application uses integers up to 10^40, so you're probably consing lots of temporary bignums. These should get collected by the EGC, but perhaps the bugs in EGC are causing your problem. If you can't upgrade to 4.0, maybe there is a similar patch available for 3.0; ask Lucid. By the way, the latest patch level of 3.0 is 3.0.5, but you're still running 3.0.1; you should at least try to get the latest set of patches for your version. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
mdb@zero.arc.ab.ca (Mark Brinsmead) (05/02/91)
In article <1991May1.193431.6482@Think.COM>, barmar@think.com (Barry Margolin) writes: |> If you can't upgrade to 4.0, maybe there is a similar patch available for |> 3.0; ask Lucid. By the way, the latest patch level of 3.0 is 3.0.5, but |> you're still running 3.0.1; you should at least try to get the latest set |> of patches for your version. |> Interesting point. Are patches available for anonymous ftp from any site on the net, or do I have to obtain them from the vendor (in my case, SUN)? It would (probably) be much easier and faster to ftp patches, especially since this would allow me to check for the existance of (new) patches for bugs that I am not yet aware of! (Gee, it sure would be nice to fix a bug *before* I find it!) Anyone from Lucid listening? -- Mark Brinsmead Alberta Research Council