gcl-devel
[Top][All Lists]
Advanced

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

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


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

Greetings!

Bill Pase <address@hidden> writes:

> 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.
> 

OK, would you mind please 

1) reporting the memory on your system
2) rerunning instructing 'time' to report the full statistics in the
   default format, e.g.          

        %Uuser %Ssystem %Eelapsed %PCPU (%Xtext+%Ddata %Mmax)k
         %Iinputs+%Ooutputs (%Fmajor+%Rminor)pagefaults %Wswaps

I'm thinking you were swapping.

I'd like to reporduce any performance discrepancies locally if possible.

Take care,



> /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
> 
> 
> 

-- 
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]