On Wed, Jan 17, 2024 at 07:29:58PM +0800, Qian Yun wrote:
> I think Dima gives a good advice, WDYT, Waldek?
>
> - Qian
>
> diff --git a/configure.ac b/configure.ac
> index 073f3e96..99426fb1 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -190,13 +190,16 @@ if test -z "$fricas_lisp" ; then
> use --with-lisp option to tell FriCAS
> how to invoke your Lisp])
> fi
> + FRICAS_LISP="$FRICAS_LISP --dynamic-space-size 2048"
> fricas_lisp=$FRICAS_LISP
> else
> ## Honor use of Lisp image specified on command line
> + if "$fricas_lisp" = "sbcl" ; then
> + fricas_lisp="sbcl --dynamic-space-size 2048"
> + fi
> FRICAS_LISP=$fricas_lisp
> - AC_SUBST(FRICAS_LISP)
> - :
> fi
> +AC_SUBST(FRICAS_LISP)
>
> AC_ARG_WITH([lisp-flavor],
> [AS_HELP_STRING([--with-lisp-flavor=F],
This is problematic. When we dump image the options are
stored in the image. AFAIK in sbcl options stored in image
override (or maybe replace) command line. Consequently,
there is no way to override dynamic space size. To
get changeable behaviour default dynamic space size
must be configured at sbcl build time.
Basically, there are several bad decisions on sbcl side
(and Linux/Unix side):
1) no ability to change sbcl dynamic space size at runtime
2) Linux confuses "memory" with address space, there is
no working limit on real memory
3) too low default setting of sbcl dynamic space size
4) sbcl handling of options stored in images
5) large memory use by sbcl compiler
Within those constraints there is no good solution:
- building our own sbcl to get sane defults would be
disliked by distributions
- setting new size in images means that it is no longer
changable
- propagating size option to all invocations of images
spreads out sbcl specific workarounds troughout makefiles.
Just to explain better technical constrains:
- sbcl needs single continuous region on memory. If it were
possible to allocate address space first and incrementally
allocate memory at prescribed addresses at least in principle
sbcl could use this
- if it were possible to limit used memory sbcl could allocate
big area of memory (utilizing Linux overcommit). Actual
limiting could be in sbcl (I am not aware of any such possiblity)
or via ulimit (but again, AFAIK there is no possiblity to
limit used (as opossed to allocated) memory).
- we could live with 1G default if sbcl compiler could
operate within the limit. But apparently, somewhat longer
linear stretches of code seem to trigger very bad behaviour
of sbcl. In principle such code is easiest to compile and
can be handled by linear time/space method. And I am not
talking about very long sequences.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/Za8SDBdN6DYhsyDX%40fricas.org.
