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

[Camm Maguire]

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