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

[Bill Pase]

I did the 2.6.1 tests with the pre-built image for debian pointed to from the 
ACL2 page.  I didn't change any settings before running the test.

The 2.4.1 test was built with gcc 2.96 (on a redhat 7.2 system).  Gain I 
just run the makes and the tests, no settings were changed.

/bill


On May 14, 2004 05:47 pm, Matt Kaufmann wrote:
> 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