gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: ACL2 2.8 Debian packages


From: Camm Maguire
Subject: [Gcl-devel] Re: ACL2 2.8 Debian packages
Date: 13 May 2004 18:30:49 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]