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

[Bill Pase]

Camm,

Ok here is the information for you to take a look at:

1)  The system is a p3-450 with 256mb ram,
2)  debian-gnu-linux-gcl-saved_acl2.gcl.logfile shows the version and 'room',
3)  make-certify.logfile-summary shows the make certify and 'time' results,

I took the details out of the certify, but I can send them if they might be 
useful, and I kept the rest of the directory, so I can send whatever.

Let me know if there is anything else you need?

Regards,

Bill


On May 18, 2004 03:20 pm, Camm Maguire wrote:
> 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

debian-gnu-linux-gcl-saved_acl2.gcl.logfile
Description: Text document

make-certify.logfile-summary
Description: Text document