gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] GCL on Mac


From: Matt Kaufmann
Subject: Re: [Gcl-devel] GCL on Mac
Date: Sat, 23 Jan 2016 12:08:52 -0600

Thanks, Camm.  Is there user-level documentation available for
si::*code-block-reserve*, GCL_MEM_MULTIPLE, and
GCL_MULTIPROCESS_MEMORY_POOL?  I found
https://lists.gnu.org/archive/html/gcl-devel/2015-11/msg00018.html
but, for example, it doesn't really tell me, as a dumb user, what to
do.  For now I'll just use your suggestion below of
GCL_MEM_MULTIPLE=0.125 for my -j 8 runs.

Thanks --
-- Matt
> From: Camm Maguire <address@hidden>
> Date: Sat, 23 Jan 2016 08:40:37 -0500
> 
> Greetings, and thanks so much for your feedback!
> 
> As you know one of the release goals of 2.6.13 is to be able to use all
> available memory effectively, i.e. no compile-time maxpages.  This
> introduced two problems, 1) loading code over 2Gb limit, and 2) staying
> out of swap.  As for the first, we have si::*code-block-reserve*.  As
> for the second, we have those tuning environment variables I've
> mentioned before.  You should be good at present for example by setting
> GCL_MEM_MULTIPLE=0.125, among other possibilities
> (e.g. GCL_MULTIPROCESS_MEMORY_POOL).
> 
> Though this does unlock performance gains, I'm unhappy about the extra
> tuning variables.  In general, I'd like things to 'just work' by default
> and possibly have tuning variables available for optional use by
> experts.
> 
> It is conceivable that I could have gcl recognize the 2Gb limit and
> compile code with the slower large memory model once reached, though
> this code will lose about 10%.  It is also possible that GCL does some
> sort of load monitoring, somewhat like the MULTIPROCESS_POOL but from a
> system-wide level, instead of gauging memory at startup.  The general
> problem here is that GCL cannot shrink its heap, so the maneuverability
> once near saturation is detected is limited.  There is a branch which
> implements a copying collector that would alleviate this, but I am
> hoping to avoid this for this release.
> 
> Anyway, suggestions as always most appreciated.
> 
> Take care,
> 
> Matt Kaufmann <address@hidden> writes:
> 
> > Hi, Camm --
> >
> > FYI, I tried the latest ACL2 and GCL ANSI on my Mac.
> > Things went pretty well for awhile -- no failures -- but
> > eventually memory usage got out of hand (I can send
> > you screenshots of windows about that if you want) and
> > I rebooted my machine.  Perhaps if I'd run make with
> > something less than -j 8 I wouldn't have had this problem
> > -- I saw at least one job of over 7 GB and I only have
> > 16 GB of RAM.
> >
> > I rarely run GCL on my Mac anyhow, so no big deal;
> > but I thought I'd mention this in case you're interested.
> >
> > -- Matt
> >
> >
> >
> >
> 
> -- 
> Camm Maguire                                      address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gcl-devel
> 



reply via email to

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