Re: [Gcl-devel] Re: ACL2 2.8 Debian packages

[Matt Kaufmann]

Thanks, Camm.  Perhaps Bill Pase's experiments were done with a version of
2.6.1 that didn't have the improved garbage collection, in which case I wonder
if the large image size was more of an issue there.

-- Matt
   Cc: address@hidden, address@hidden, address@hidden,
           address@hidden, address@hidden,
           address@hidden
   From: Camm Maguire <address@hidden>
   Date: 14 May 2004 17:43:00 -0400
   User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
   Content-Type: text/plain; charset=us-ascii
   X-SpamAssassin-Status: No, hits=-4.3 required=5.0
   X-UTCS-Spam-Status: No, hits=-366 required=180

   Greetings!

   Matt Kaufmann <address@hidden> writes:

   > Thanks, Camm; that's excellent news.  A more stressful test would be to run
   > (time make regression-fresh) after obtaining the books/workshops/ books.  
Let
   > me know if you want me to try that using images you've already built at 
UT, or
   > if you want guidance in obtaining books/workshops/.
   > 

   Thanks for the suggestions.  I'd first like to see some of the
   purported effects in a test which doesn't take too much time here
   locally if possible.  So far I cannot reproduce any size effect.

   Here is a run with 2.4.1, which cannot compile with current gcc-3.3
   (only 2.95), but is run on the same machine with different libraries
   (i.e. Debian stable):

       MAXPAGES   time make certify-books-fresh
       --------   -----------------------------
       32*1024    real 100m17.612s  user 98m52.380s  sys 1m24.460s

   Due to the differences cited above, in addition to the fact that this
   version of gcl did not have compiler::link and made its executables in
   a different way, I am unsure if this result is distinguishable from
   random noise.  Another difference -- this gcl did not have bfd
   linking: one can get a somewhat smaller image on sparc and i386 only
   by using --disable-statsysbfd --enable-custreloc.  I'll try to give
   this option a whirl with 2.6.1.

   If I can find a simple test showing a >=20% effect as reported below
   in a couple of instances, we'd have something to go on.

   Take care,

   > Thanks --
   > -- Matt
   >    Cc: address@hidden, address@hidden, address@hidden,
   >       address@hidden, address@hidden,
   >       address@hidden
   >    From: Camm Maguire <address@hidden>
   >    Date: 13 May 2004 18:30:49 -0400
   >    User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
   >    Content-Type: text/plain; charset=us-ascii
   >    X-SpamAssassin-Status: No, hits=-4.3 required=5.0
   >    X-UTCS-Spam-Status: No, hits=-261 required=180
   > 
   >    Greetings!  OK, first pass:
   > 
   >    GCL 2.6.1:
   > 
   >    MAXPAGES   time make certify-books-fresh
   >    --------   -----------------------------
   >    32*1024    real 105m4.456s  user 103m24.360s  sys 1m40.760s
   >    128*1024   real 101m10.311s user 99m21.130s   sys 1m51.900s
   >    256*1024   real 100m59.879s user 98m33.030s   sys 2m25.420s
   > 
   >    All these had the preallcoation disabled.  Machine:
   > 
   >            total       used       free     shared    buffers     cached
   >    Mem:        515720     226624     289096          0       4216     
116056
   >    -/+ buffers/cache:     106352     409368
   >    Swap:       827308     257888     569420
   > 
   >    Intel 2.4Ghz
   > 
   >    In sum, we see what we might expect, some increasing system time load
   >    due to the larger image, and a decreasing user time load due to fewer
   >    GC calls.  I think beyond 128*1024 is at the point of diminishing
   >    returns. 
   > 
   >    Now its possible some of the other benchmarks were swapping.  If so,
   >    perhaps it might make sense to choose the hole at runtime based on the
   >    available memory.
   > 
   >    Take care,
   > 
   >    Matt Kaufmann <address@hidden> writes:
   > 
   >    > Thanks very much, Camm.  I'm delighted that you're doing test runs 
(with ACL2,
   >    > I hope); I'm sure they'll be useful.
   >    > 
   >    > -- Matt
   >    >    Cc: address@hidden, address@hidden, address@hidden,
   >    >          address@hidden, address@hidden,
   >    >          "Mike Thomas" <address@hidden>
   >    >    From: Camm Maguire <address@hidden>
   >    >    Date: 13 May 2004 11:25:40 -0400
   >    >    User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
   >    >    Content-Type: text/plain; charset=us-ascii
   >    >    X-SpamAssassin-Status: No, hits=-4.3 required=5.0
   >    >    X-UTCS-Spam-Status: No, hits=-80 required=180
   >    > 
   >    >    Greetings!
   >    > 
   >    >    Matt Kaufmann <address@hidden> writes:
   >    > 
   >    >    > Warren, Camm --
   >    >    > 
   >    >    > I've been meaning to send an email about the issue of large 
MAXPAGES (raised by
   >    >    > Warren in the email to which this is a response) with respect to 
performance.
   >    >    > In summary: I'm concerned that increasing default MAXPAGES will 
cause
   >    >    > significant slowdowns for ACL2/GCL users.
   >    >    > 
   >    >    > First, recall that there was a significant slowdown (59%) in 
doubling the
   >    >    > MAXPAGES using recent GCLs with the improved GC and with no ACL2
   >    >    > pre-allocation.
   >    >    > 
   >    >    > Second, Bill Pase recently sent me an email with these 
performance numbers for
   >    >    > running ACL2:
   >    >    > 
   >    >    >     P3 450mhz GCL 2.6.1 Win98 - 14hr
   >    >    >     P3 450mhz GCL 2.6.1 Linux - 7hr42m
   >    >    >     P3 450mhz CMUCL 18e Linux - 7hr19m
   >    >    >     P3 450mhz GCL 2.4.1 Linux - 6hr24m
   >    >    > 
   >    > 
   >    >    Thanks for bringing this to my attention.  I'm doing a few test 
runs
   >    >    myself.
   >    > 
   >    >    First, the Windows issue is entirely, to my understanding, a lack 
of
   >    >    SGC on this platform, due to a lack of mprotect and/or SIGSEGV
   >    >    trapping.  Perhaps Mike could comment on the possibilities in the 
road
   >    >    ahead on this issue.  Without SGC, every GC will page fault all the
   >    >    memory in the heap, which can be quite expensive for big images.
   >    > 
   >    >    Secondly, I feel the most likely issue concerning maxpages is not 
this
   >    >    value itself, but rather the defaults for the other page sizes that
   >    >    flow from it.  We've recently discussed on the gcl-devel list what 
a
   >    >    sensible default strategy would be for the many size settings in 
GCL,
   >    >    and concluded (at least thus far) that keying all of them to 
MAXPAGE
   >    >    would be best.  Hence at present, the hole defaults to MAXPAGE/10, 
and
   >    >    the initial relocatable area to ~ MAXPAGE/30.  This area is added 
to
   >    >    the core whether it is used or not, unlike the rest of the heap 
which
   >    >    is added only as needed. Of course this conclusion is only 
tentative
   >    >    at best.  I think it best to report virtual memory sizes and page
   >    >    fault counts reported by the OS in statistics like these to get a
   >    >    better handle on what is going on.  Of course, I'm always open to
   >    >    suggestions, as I am far from the expert here.
   >    > 
   >    >    As to the suggestion of making maxpages user settable, this is a 
great
   >    >    idea which I've been intending to implement for some time, in 
addition
   >    >    to the other static queue size settings for pretty-printing,
   >    >    etc. recently brought up by Warren.  It would entail moving 
type_map,
   >    >    sgc_type_map, and a few local stack allocations to relocatable 
block
   >    >    allocations and ensuring proper accessibility under GC.  These 
changes
   >    >    are a bit too involved for 2.6.x, but hopefully can be addressed in
   >    >    2.7.x.  If anyone wants to try their hand at a patch, I'd be most
   >    >    happy to look at it and test.
   >    > 
   >    >    Take care,
   >    > 
   >    >    > Notice the second and fourth lines above:  there is a 
significant slowdown from
   >    >    > GCL 2.4.1 to GCL 2.6.1.  But it turns out that Bill's GCL build 
for 2.6.1 had
   >    >    > four times the MAXPAGES as his 2.4.1:  131072 maximum pages vs. 
32768 maximum
   >    >    > pages.  I can imagine that this accounts for most or all of the 
slowdown.
   >    >    > 
   >    >    > Thanks --
   >    >    > -- Matt
   >    >    >    Date: Thu, 13 May 2004 07:02:00 -0500
   >    >    >    From: "Warren A. Hunt Jr." <address@hidden>
   >    >    >    CC: address@hidden, address@hidden, address@hidden
   >    >    > 
   >    >    >    Hi Camm,
   >    >    > 
   >    >    >    Thank you so much for building all of the Debian ACL2 
packages.
   >    >    > 
   >    >    >    I don't know what size you are using for MAXPAGES, but since 
you are
   >    >    >    going to as much trouble as you are, would you consider 
setting
   >    >    >    MAXPAGES to maximum for the 32-bit images?  Having more space 
is such
   >    >    >    a performance boost for ACL2, that I would like to see all of 
the
   >    >    >    images have as much space as possible.
   >    >    > 
   >    >    >    I don't know what to say as far as a default for the 64-bit 
images,
   >    >    >    but again being able to use more space (with the default 
settings)
   >    >    >    woudld be great.  Just to get back to where we are with 
32-bit images,
   >    >    >    we need MAXPAGES to be twice as large as on the 64-bit 
images.  May
   >    >    >    I recommend that the 64-bit images have an 8 or even better a 
16-GByte
   >    >    >    default memory size?
   >    >    > 
   >    >    >    Thanks,
   >    >    > 
   >    >    >    Warren
   >    >    > 
   >    >    > 
   >    >    > 
   >    > 
   >    >    -- 
   >    >    Camm Maguire                                               
address@hidden
   >    >    
==========================================================================
   >    >    "The earth is but one country, and mankind its citizens."  --  
Baha'u'llah
   >    > 
   >    > 
   >    > 
   > 
   >    -- 
   >    Camm Maguire                                            address@hidden
   >    
==========================================================================
   >    "The earth is but one country, and mankind its citizens."  --  
Baha'u'llah
   > 
   > 
   > _______________________________________________
   > Gcl-devel mailing list
   > address@hidden
   > http://mail.gnu.org/mailman/listinfo/gcl-devel
   > 
   > 
   > 

   -- 
   Camm Maguire                                         address@hidden
   ==========================================================================
   "The earth is but one country, and mankind its citizens."  --  Baha'u'llah