Re: [Gcl-devel] Re: possible lisp reader enhancement/modification

[Vadim V. Zhytnikov]

Matt Kaufmann пишет:

> Hi --
>
> Sorry I couldn't reply soon (I just returned from vacation).
>
> I'm also really sorry to say that I can't provide the test example, since it's
> derived directly from AMD design data and I think it would take considerable
> effort to "sanitize" it, if that's even possible.  But below are some details
> from the run, and if someone cares to suggest some allocate settings then I'd
> be happy to re-run.  Anyhow, here's some info that may halp.
>
> Here I'm focusing on one run from a suite of runs.  The timing was as follows:
>
> ACL2 built on GCL:
> real    93m14.066s
> user    92m47.830s
> sys     0m16.260s
>
> ACL2 built on Allegro CL dynamic runtime:
> real    32m40.528s
> user    32m21.530s
> sys     0m10.140s
>
> I built ACL2 by starting with modest allocations and causing growth to occur
> slowly (details upon request).   Here is the room available when I first
> started up ACL2.
>
>   ACL2>(room)
>   2917/2917 82.0%CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
>    100/100   18.4%    FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE READTABLE NIL
>    400/400   35.2%    SYMBOL STREAM
>      1/2     37.2%    PACKAGE
>      5/38    13.8%    ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME CCLOSURE 
> FAT-STRING
>    200/200   46.4%    STRING
>    400/400    1.8%    CFUN BIGNUM
>     40/40    56.7%    SFUN GFUN CFDATA SPICE NIL
>
>      1/100            contiguous (1 blocks)
>        1000           hole
>        500    0.1%    relocatable
>
>    4063 pages for cells
>    5564 total pages
>   55769 pages available
>    4203 pages in heap but not gc'd + pages needed for gc marking
>   65536 maximum pages
>
>   ACL2>
>
> At the end of the run, (room) gave the following.
>
>   ACL2>(room)
>   50251/51062 98.9%350CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
>    245/225   62.6% 77 FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE READTABLE NIL
>    790/900   99.3%  2 SYMBOL STREAM
>      1/2     64.1%    PACKAGE
>     29/38     3.2%    ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME CCLOSURE 
> FAT-STRING
>    450/450   97.4%3916STRING
>    400/400   74.9%  9 CFUN BIGNUM
>     43/60    97.1%  1 SFUN GFUN CFDATA SPICE NIL
>
>   6414/6553       669 contiguous (17 blocks)
>        382            hole
>        750   68.2%669 relocatable
>
>   52209 pages for cells
>   59755 total pages
>     710 pages available
>    5071 pages in heap but not gc'd + pages needed for gc marking
>   65536 maximum pages
>
>   ACL2>
>
> I particularly noticed a lot of string GCs, such as:
>
> [SGC for 93 STRING pages..(11793 writable)..(T=14).GC finished]
>
> Here are total counts of gc messages.
>
> [SGC for ... CONS pages]:              350
> [SGC for ... STRING pages]:           3916
> [SGC for ... FIXNUM pages]:             77
> [SGC for ... SYMBOL pages]:              2
> [SGC for ... CFUN pages]:                9
> [SGC for ... SFUN pages]:                1
> [SGC for 0 CONTIGUOUS-BLOCKS pages]:    12
> [SGC for 0 RELOCATABLE-BLOCKS pages]:  553
>
> I can send you all 4920 lines of SGC messages if you like.  I also got this 
> count:
>
> [GC for ... RELOCATABLE-BLOCKS pages]: 116

Try to call
  (si::gbc-time 0)
before starting ACL2 test. This function activates
internal GC timing counter.  Finally (si::gbc-time) will
give total time spent by GCL in GC (the sum of T=... in GC messages)
in some internal units (1/100 of second as far as I recall).
I'm perfectly sure that from 60% to 90% of total time
is wasted in the GC.  If you increase preallocated space
(especially for storage types which cause more frequent GC)
then total GC time should go down significantly keeping
  (net time) = (total time) - (total GC time)
approximately constant.

--
     Vadim V. Zhytnikov

      <address@hidden>
     <address@hidden>