[Top][All Lists]
[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
- [Gcl-devel] Re: ACL2 2.8 Debian packages, Camm Maguire, 2004/05/13
- [Gcl-devel] Re: ACL2 2.8 Debian packages, Matt Kaufmann, 2004/05/13
- [Gcl-devel] Re: ACL2 2.8 Debian packages, Camm Maguire, 2004/05/13
- [Gcl-devel] Re: ACL2 2.8 Debian packages, Matt Kaufmann, 2004/05/13
- Re: [Gcl-devel] Re: ACL2 2.8 Debian packages, Camm Maguire, 2004/05/14
- Re: [Gcl-devel] Re: ACL2 2.8 Debian packages, Matt Kaufmann, 2004/05/14
- Re: [Gcl-devel] Re: ACL2 2.8 Debian packages, Bill Pase, 2004/05/16
- Re: [Gcl-devel] Re: ACL2 2.8 Debian packages,
Camm Maguire <=
- Re: [Gcl-devel] Re: ACL2 2.8 Debian packages, Bill Pase, 2004/05/20
- RE: [Gcl-devel] Re: ACL2 2.8 Debian packages, Mike Thomas, 2004/05/23
- Re: [Gcl-devel] Re: ACL2 2.8 Debian packages, Camm Maguire, 2004/05/27
- RE: [Gcl-devel] Re: ACL2 2.8 Debian packages, Mike Thomas, 2004/05/28