GCL and compiler::*default-large-memory-model-p*

[Qian Yun]

I need the patch posted in thread "FriCAS and GCL" (February 11 2023)
to compile FriCAS with gcl-2.6.14.

So shall we include it?

- Qian


--- trunk/src/lisp/Makefile.in 2022-07-16 14:43:58.443666098 +0200
+++ dist/src/lisp/Makefile.in 2023-02-11 15:36:50.248556407 +0100
@@ -68,7 +68,8 @@
' (compiler::emit-fn t))' \
' (when (fboundp (quote si::sgc-on))' \
' (si::sgc-on nil))' \
- ' (setq compiler::*default-system-p*
t))"' \
+ ' (setq compiler::*default-system-p*
t)' \
+ ' (setq compiler::*default-large-memory-model-p*
t))"' \
' si::*system-directory* (quote (list ".lsp")))' \
' "$(lisp_c_objects) $(fricas_c_runtime_extra)")' \
| $(FRICAS_LISP)

[Waldek Hebisch]

On Sun, Oct 29, 2023 at 05:13:58PM +0800, Qian Yun wrote:
> I need the patch posted in thread "FriCAS and GCL" (February 11 2023)
> to compile FriCAS with gcl-2.6.14.
>
> So shall we include it?

Have you tried to set GCL_MEM_MULTIPLE so that GCL uses slightly
less than 2Gb of memory? With such setting patch below should
be not needed. And IME parallel builds with GCL are usable
only with sufficiently small GCL_MEM_MULTIPLE (otherwise
system is thrashing).

Setting *default-large-memory-model-p* means that generated
code is slower. I do not know how much slower, old info
said that about 7-10% slower. We should do some testing
to know.

>
> - Qian
>
>
> --- trunk/src/lisp/Makefile.in 2022-07-16 14:43:58.443666098 +0200
> +++ dist/src/lisp/Makefile.in 2023-02-11 15:36:50.248556407 +0100
> @@ -68,7 +68,8 @@
> ' (compiler::emit-fn t))' \
> ' (when (fboundp (quote si::sgc-on))' \
> ' (si::sgc-on nil))' \
> - ' (setq compiler::*default-system-p*
> t))"' \
> + ' (setq compiler::*default-system-p* t)'
> \
> + ' (setq compiler::*default-large-memory-model-p* t))"'
> \
> ' si::*system-directory* (quote (list ".lsp")))' \
> ' "$(lisp_c_objects) $(fricas_c_runtime_extra)")' \
> | $(FRICAS_LISP)
>

> --
> 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 fricas-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/318057da-c7ff-47da-9614-9d6b3ba198b2%40gmail.com.

--
Waldek Hebisch

[Qian Yun]

On 10/30/23 09:28, Waldek Hebisch wrote:
>
> Have you tried to set GCL_MEM_MULTIPLE so that GCL uses slightly
> less than 2Gb of memory? With such setting patch below should
> be not needed. And IME parallel builds with GCL are usable
> only with sufficiently small GCL_MEM_MULTIPLE (otherwise
> system is thrashing).
>
> Setting *default-large-memory-model-p* means that generated
> code is slower. I do not know how much slower, old info
> said that about 7-10% slower. We should do some testing
> to know.

I run all tests in src/input, the results are:

GCL_MEM_MULTIPLE:

real 4m38.479s
user 4m14.601s
sys 0m25.861s

large-memory-model-p:

real 4m53.449s
user 4m7.267s
sys 0m48.138s

So with *default-large-memory-model-p*, the code spends much more time
in kernel space, but the overall slow down is 5%.

- Qian

[Waldek Hebisch]

On Mon, Oct 30, 2023 at 07:26:04PM +0800, Qian Yun wrote:
>
>
> On 10/30/23 09:28, Waldek Hebisch wrote:
> >
> > Have you tried to set GCL_MEM_MULTIPLE so that GCL uses slightly
> > less than 2Gb of memory? With such setting patch below should
> > be not needed. And IME parallel builds with GCL are usable
> > only with sufficiently small GCL_MEM_MULTIPLE (otherwise
> > system is thrashing).
> >
> > Setting *default-large-memory-model-p* means that generated
> > code is slower. I do not know how much slower, old info
> > said that about 7-10% slower. We should do some testing
> > to know.
>
> I run all tests in src/input, the results are:
>
> GCL_MEM_MULTIPLE:
>
> real 4m38.479s
> user 4m14.601s
> sys 0m25.861s
>
> large-memory-model-p:
>
> real 4m53.449s
> user 4m7.267s
> sys 0m48.138s
>
> So with *default-large-memory-model-p*, the code spends much more time
> in kernel space, but the overall slow down is 5%.

I run both version with GCL_MEM_MULTIPLE=0.03, test time was the same,
build time was about 3% larger. Overhead seem to be reasonably low,
so I commited the patch. FYI, I see essentially the same kernel
time in both cases.

BTW, I also tested ECL on the same machine. The results are
(all parallel with -j 20):

GCL, old setting:

real 0m57,734s
user 3m54,550s
sys 0m33,744s

GCL, *default-large-memory-model-p*:

real 0m56,231s
user 3m54,650s
sys 0m32,983s

ECL 21.2.1:

real 2m54,068s
user 21m57,290s
sys 1m22,064s

ECL 23.9.9:

real 2m59,574s
user 25m4,375s
sys 1m24,747s

sbcl 2.3.8:

real 0m39,432s
user 2m14,932s
sys 0m12,555s


So, on my machine GCL is about 1.73 times slower than sbcl,
ECL 21.2.1 is 9.76 times slower than sbcl and ECL 23.9.9 is
11.14 times slower than sbcl. So, ECL is _much_ slower than
GCL and apparantly with new versions ECL is getting slower...

--
Waldek Hebisch