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