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 11:25:40 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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




reply via email to

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