FriCAS CheckBench and errors with different CL flavors

[Grégory Vanuxem]

Hello,

Here are some results from 'time make check' with different Common
Lisp flavors. FriCAS is built with './configure --with-x=no
--with-lisp=path_to_cl'. FriCAS cloned from GitHub as of today with
very minor modifications. I used roswell to test them on my x86-64
Intel laptop with WSL2. Roswell allows easy installation of different CL
implementations, see: https://roswell.github.io. There is even a .deb
package on this web site if you don't know Roswell and want to give it
a try.

On my machine for example, here is a list of installable CLs. Roswell
installs them in $HOME/.roswell/ by default.
┌──(greg㉿ellipse)-[~/jfricas]
└─$ ros install
Usage:
To install a new Lisp implementation:
ros install impl [options]
or a system from the GitHub:
ros install fukamachi/prove/v2.0.0 [repository... ]
or an asdf system from quicklisp:
ros install quicklisp-system [system... ]
or a local script:
ros install ./some/path/to/script.ros [path... ]
or a local system:
ros install ./some/path/to/system.asd [path... ]

Candidates impls for installation are:
abcl-bin
allegro
ccl-bin
clasp-bin
clasp
clisp
cmu-bin
ecl
mkcl
sbcl-bin
sbcl-head
sbcl
sbcl-source

So I installed:
SBCL-2.3.0 with
*features*
(:ARENA-ALLOCATOR :X86-64 :GENCGC :64-BIT :ANSI-CL :COMMON-LISP :ELF
:IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN :PACKAGE-LOCAL-NICKNAMES
:SB-CORE-COMPRESSION :SB-LDB :SB-PACKAGE-LOCKS :SB-THREAD :SB-UNICODE
:SBCL :UNIX)

CCL-1.12.1 with
*features*
(:PRIMARY-CLASSES :COMMON-LISP :OPENMCL :CCL :CCL-1.2 :CCL-1.3
:CCL-1.4 :CCL-1.5 :CCL-1.6 :CCL-1.7 :CCL-1.8 :CCL-1.9 :CCL-1.10
:CCL-1.11 :CCL-1.12 :CLOZURE :CLOZURE-COMMON-LISP :ANSI-CL :UNIX
:OPENMCL-UNICODE-STRINGS :IPV6 :OPENMCL-NATIVE-THREADS
:OPENMCL-PARTIAL-MOP :MCL-COMMON-MOP-SUBSET :OPENMCL-MOP-2
:OPENMCL-PRIVATE-HASH-TABLES
:STATIC-CONSES-SHOULD-WORK-WITH-EGC-IN-CCL :PACKAGE-LOCAL-NICKNAMES
:X86-64 :X86_64 :X86-TARGET :X86-HOST :X8664-TARGET :X8664-HOST
:LINUX-HOST :LINUX-TARGET :LINUXX86-TARGET :LINUXX8664-TARGET
:LINUXX8664-HOST :64-BIT-TARGET :64-BIT-HOST :LINUX
:LITTLE-ENDIAN-TARGET :LITTLE-ENDIAN-HOST)

ECL-21.2.1 with
*features*
(:WALKER :CDR-1 :CDR-5 :LINUX :FORMATTER :CDR-7 :ECL-WEAK-HASH
:LITTLE-ENDIAN :ECL-READ-WRITE-LOCK :LONG-LONG :UINT64-T :UINT32-T
:UINT16-T :COMPLEX-FLOAT :LONG-FLOAT :UNICODE :DFFI :CLOS-STREAMS
:CMU-FORMAT :UNIX :ECL-PDE :DLOPEN :CLOS :THREADS :BOEHM-GC :ANSI-CL
:COMMON-LISP :FLOATING-POINT-EXCEPTIONS :IEEE-FLOATING-POINT
:PACKAGE-LOCAL-NICKNAMES :CDR-14 :PREFIXED-API :FFI :X86_64 :COMMON
:ECL)

CMU (i386) - 21d with
*features*
(:GERDS-PCL :PCL-STRUCTURES :PORTABLE-COMMONLOOPS :PCL :CMU21 :CMU21D
:PYTHON :MODULAR-ARITH :MP :X86 :RELOCATABLE-STACKS :SSE2
:LINKAGE-TABL :RELATIVE-PACKAGE-NAMES :EXECUTABLE :ELF :LINUX :GLIBC2
:UNIX :RANDOM-XOROSHIRO :GENCGC :CMUCL :UNICODE :COMPLEX-FP-VOPS
:HASH-NEW :ALIEN-CALLBACK :DOUBLE-DOUBLE :HEAP-OVERFLOW-CHECK
:STACK-CHECKING :COMMON-LISP :ANSI-CL :IEEE-FLOATING-POINT :CMU)

CLISP 2.49.20210628.gitde01f0f with 'apt install clisp 'with
*features*
(:READLINE :REGEXP :WILDCARD :SYSCALLS :I18N :LOOP :COMPILER :CLOS
:MOP :CLISP :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER
:LOGICAL-PATHNAMES :SOCKETS :GENERIC-STREAMS :SCREEN :FFI :GETTEXT
:UNICODE :BASE-CHAR=CHARACTER :WORD-SIZE=64 :PC386 :UNIX)

ABCL-1.9.0 with
*features*
(:NIO :X86-64 :UNIX :LINUX :JAVA-17 :JVM-17.0.5 :ARMEDBEAR :ABCL
:COMMON-LISP :ANSI-CL :CDR6 :MOP :PACKAGE-LOCAL-NICKNAMES)

GCL with 'apt install gcl' - GCL-2.6.14 released the 20230113 with
*features*
(:COMPILER :NUMLIB :SDEBUG :DEFPACKAGE :LARGE-MEMORY-MODEL :GNU-LD
:XGCL :UNEXEC :NATIVE-RELOC :EDITLINE :TRUNCATE_USE_C
:CLX-LITTLE-ENDIAN :BSD :GNU :LINUX :X86_64 :SGC :IEEE-FLOATING-POINT
:UNIX :GMP :GCL :AKCL :COMMON :KCL)

=====================================================
SBCL:
no unexpected failures

real 1m31,358s
user 1m28,217s
sys 0m3,292s
----------------------------------------------------------------------------------------------
CCL:
4 failing files:

agcd.output: 1
integ.output: 3
lodof.output: 1
mantepse.output: 1

real 3m45,449s
user 3m41,144s
sys 0m3,825s
----------------------------------------------------------------------------------------------
CMU:
1 failing files:
finite.output: 1

real 4m54,976s
user 4m50,230s
sys 0m4,917s
---------------------------------------------------------------------------------------------
ECL:
no unexpected failures

real 6m44,441s
user 7m14,735s
sys 0m18,556s
-------------------------------------------------------------------------------------------------
CLISP:
no unexpected failures
make[1] : on quitte le répertoire « /home/greg/jfricas-sbcl/src/input »

real 19m17,411s
user 18m23,035s
sys 0m30,544s
----------------------------------------------------------------------------------------------
ABCL:
checking PREGENERATED... ""
checking Lisp implementation... Armed Bear Common Lisp 1.9.0
Java 17.0.5 Debian
OpenJDK 64-Bit Server VM
Low-level initialization completed in 0.359 seconds.
Startup completed in 2.023 seconds.
Type ":help" for a list of available commands.
CL-USER(1): abcl
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
configure: error: We do not know how to build FriCAS this
/home/greg/.roswell/impls/x86-64/linux/abcl-bin/1.9.0/abcl
------------------------------------------------------------------------------------------------
GCL:
--->/home/greg/jfricas-sbcl/src/algebra/U64INT.spad-->U64Int((qconvert
(% (Integer)))): Not documented!!!!
U64Int is already explicitly exposed in frame initial
U64Int will be automatically loaded when needed from
/home/greg/jfricas-sbcl/src/algebra/U64INT.NRLIB/U64INT

)lisp (make-databases nil nil)
"building operation.daase"
"building category.daase"
>> System error:
(1) -> mv: cannot stat 'category.daase': No such file or directory
mv: cannot stat 'compress.daase': No such file or directory
mv: cannot stat 'interp.daase': No such file or directory
mv: cannot stat 'operation.daase': No such file or directory
make[3]: *** [Makefile:622: stamp-db] Error 1

========================================================

As you can see the "bench" reflects approximately what Waldek reported
in the INSTALL file.
But it remains that I was not able to build FriCAS with ABCL nor GCL,
and importantly too the 4 Clozure CL errors.
I attached diff-s from .output files where errors occur between the
outputs of SBCL and the other ones.
It's really a pity for CCL since it behaves very nicely with Julia
whereas SBCL does not (with Julia signals handling bypassed as
suggested by Waldek, thanks to him). More to come later.

Regards,
__
Greg

PS1: Qian, I CCed you because of the ABCL build failure. That could
come from the OpenJDK-17.0..5 JRE though or a bad configuration
option.

PS2: Camm, I CCed you too to let you know I think the Debian gcl
package requires libreadline-dev in 'Depends' or 'Suggests' and maybe
some Xorg dev packages. Ex.: directly at the beginning of FriCAS
build, just after compilation of two C files, (compiler::link ..)
passes -lgcl -lX11 -lm -ldl -lgmp -ltirpc -lreadline to ld. I may be
wrong though, and it could be up to the user to install them himself.

[Waldek Hebisch]

On Wed, Jan 25, 2023 at 01:49:31AM +0100, Grégory Vanuxem wrote:
> Hello,
>
> Here are some results from 'time make check' with different Common
> Lisp flavors. FriCAS is built with './configure --with-x=no
> --with-lisp=path_to_cl'. FriCAS cloned from GitHub as of today with
> very minor modifications. I used roswell to test them on my x86-64
> Intel laptop with WSL2. Roswell allows easy installation of different CL
> implementations, see: https://roswell.github.io. There is even a .deb
> package on this web site if you don't know Roswell and want to give it
> a try.
>

> CCL:
> 4 failing files:
>
> agcd.output: 1
> integ.output: 3
> lodof.output: 1
> mantepse.output: 1
>

My impression is that you linked to Julia libraries. Have you checked
if failures are present when you use plan CCL, without extra libraries?


> ABCL:
> checking PREGENERATED... ""
<snip>

> configure: error: We do not know how to build FriCAS this
> /home/greg/.roswell/impls/x86-64/linux/abcl-bin/1.9.0/abcl

AFAIK code to support ABCL is not commited to the trunk. More important,
Qian used build from Lisp files. Our Makefiles depend on ability to
create executables, so there is extra work for Lisp-s that normally
do not create executable (IIUC that affects ABCL).

So no wonder that you get failure above.

> ------------------------------------------------------------------------------------------------
> GCL:
> --->/home/greg/jfricas-sbcl/src/algebra/U64INT.spad-->U64Int((qconvert
> (% (Integer)))): Not documented!!!!
> U64Int is already explicitly exposed in frame initial
> U64Int will be automatically loaded when needed from
> /home/greg/jfricas-sbcl/src/algebra/U64INT.NRLIB/U64INT
>
> )lisp (make-databases nil nil)
> "building operation.daase"
> "building category.daase"
> >> System error:
> (1) -> mv: cannot stat 'category.daase': No such file or directory
> mv: cannot stat 'compress.daase': No such file or directory
> mv: cannot stat 'interp.daase': No such file or directory
> mv: cannot stat 'operation.daase': No such file or directory
> make[3]: *** [Makefile:622: stamp-db] Error 1

I see similar thing, but worse: with default settings build fails
much earlier. When I tweak GCL_MEM_MULTIPLE=0.033 than GCL
fails in the same place.

--
Waldek Hebisch

[Grégory Vanuxem]

Le jeu. 26 janv. 2023 à 03:34, Waldek Hebisch
<de...@fricas.math.uni.wroc.pl> a écrit :

> > CCL:
> > 4 failing files:
> >
> > agcd.output: 1
> > integ.output: 3
> > lodof.output: 1
> > mantepse.output: 1
> >
>
> My impression is that you linked to Julia libraries. Have you checked
> if failures are present when you use plan CCL, without extra libraries?

Not related. And if I also remove GMP support neither.

[Grégory Vanuxem]

As a quick note for the guess failure test case *for ccl*, if I repeat
the test, I randomly obtain the expected result.

The error seems to occur during computation of the gcd line 871.
I stop here, going further is too time consuming for me, I don't have
the necessary knowledge actually.

unexpected failures: 1
expected failures: 14
unexpected passes: 0
total tests: 73
Type: Void
expected()

Compiling function expected with type () -> Void
testsuite | testcases: failed (total) | tests: failed (total)
guessing 0 (21) 0 (71)
RECOP 0 (1) 0 (1)
Type: Void
(8) -> first guessBinRat([1,1,k+1,(3*k*k+5*k+2)/2,(8*k^3+18*k*k+13*k+3)/3])

>> System error:
Error reporting error

(8) -> first guessBinRat([1,1,k+1,(3*k*k+5*k+2)/2,(8*k^3+18*k*k+13*k+3)/3])

>> System error:
Error reporting error

(8) -> first guessBinRat([1,1,k+1,(3*k*k+5*k+2)/2,(8*k^3+18*k*k+13*k+3)/3])

>> System error:
Error reporting error

(8) -> first guessBinRat([1,1,k+1,(3*k*k+5*k+2)/2,(8*k^3+18*k*k+13*k+3)/3])

(k + 1)n
( )
n
(8) ----------
k n + 1

[Camm Maguire]

Greetings, and thanks for your report!

Grégory Vanuxem <g.va...@gmail.com> writes:

> ------------------------------------------------------------------------------------------------
> GCL:
> --->/home/greg/jfricas-sbcl/src/algebra/U64INT.spad-->U64Int((qconvert
> (% (Integer)))): Not documented!!!!
> U64Int is already explicitly exposed in frame initial
> U64Int will be automatically loaded when needed from
> /home/greg/jfricas-sbcl/src/algebra/U64INT.NRLIB/U64INT
>
> )lisp (make-databases nil nil)
> "building operation.daase"
> "building category.daase"
> >> System error:
> (1) -> mv: cannot stat 'category.daase': No such file or directory
> mv: cannot stat 'compress.daase': No such file or directory
> mv: cannot stat 'interp.daase': No such file or directory
> mv: cannot stat 'operation.daase': No such file or directory
> make[3]: *** [Makefile:622: stamp-db] Error 1
>
> ========================================================
>

> PS2: Camm, I CCed you too to let you know I think the Debian gcl
> package requires libreadline-dev in 'Depends' or 'Suggests' and maybe
> some Xorg dev packages. Ex.: directly at the beginning of FriCAS
> build, just after compilation of two C files, (compiler::link ..)
> passes -lgcl -lX11 -lm -ldl -lgmp -ltirpc -lreadline to ld. I may be
> wrong though, and it could be up to the user to install them himself.
>

Does the problem above vanish if these build-dependencies are installed?

Currently on Debian, these packages are added to the build-dependency
list of *fricas*, not gcl, though an argument can be made for the latter
as lonk as compiler::link is exported. As of the moment, fricas is the
only gcl supported program making use of this function. I've added a
patch to axiom, which doubtless could be modified slightly for fricas,
to enable loading the extra C files using clines, defentry, #'load, and
#'save-system in place of the external call to ld. Of interest?

Take care,
--
Camm Maguire ca...@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

[Camm Maguire]

Greetings!

Might I please be granted git access to maintain the gcl/fricas
interface?

Take care,

Waldek Hebisch <de...@fricas.math.uni.wroc.pl> writes:

>> ------------------------------------------------------------------------------------------------
>> GCL:
>> --->/home/greg/jfricas-sbcl/src/algebra/U64INT.spad-->U64Int((qconvert
>> (% (Integer)))): Not documented!!!!
>> U64Int is already explicitly exposed in frame initial
>> U64Int will be automatically loaded when needed from
>> /home/greg/jfricas-sbcl/src/algebra/U64INT.NRLIB/U64INT
>>
>> )lisp (make-databases nil nil)
>> "building operation.daase"
>> "building category.daase"
>> >> System error:
>> (1) -> mv: cannot stat 'category.daase': No such file or directory
>> mv: cannot stat 'compress.daase': No such file or directory
>> mv: cannot stat 'interp.daase': No such file or directory
>> mv: cannot stat 'operation.daase': No such file or directory
>> make[3]: *** [Makefile:622: stamp-db] Error 1
>
> I see similar thing, but worse: with default settings build fails
> much earlier. When I tweak GCL_MEM_MULTIPLE=0.033 than GCL
> fails in the same place.
>
> --
> Waldek Hebisch

[Ralf Hemmecke]

Dear Camm,

aren't pull requests not enough?

https://github.com/fricas/fricas/pulls

In a git-world one doesn't really need write access to the "official"
repository.

Ralf

[Waldek Hebisch]

On Fri, Feb 10, 2023 at 09:11:41AM -0500, Camm Maguire wrote:
> Greetings!
>
> Might I please be granted git access to maintain the gcl/fricas
> interface?
>

Of course. What is your Github id?

BTW: After fixing issue with vanishing error messages (caused
by old GCL specific code) with enough memory I now get:

>> System error:
Condition in SYSTEM::GCL-TOP-LEVEL [or a callee]: INTERNAL-SIMPLE-ERROR: File
#p/mnt/lv0/fricas/axp8/fr-build326/src/algebra/CACHSET.NRLIB/CACHSET has been c
ompiled for a restricted address space,
and can no longer be loaded in this heap.
You can recompile with :large-memory-model-p t,
or (setq compiler::*default-large-memory-model-p* t) before recompiling.

FriCAS may load new algebra code essentially at arbitrary time
and potentially may allocate quite a lot of memory before load.
Does it mean that FriCAS should do

(setq compiler::*default-large-memory-model-p* t)

for all loadable compilations?

--
Waldek Hebisch

[Camm Maguire]

Greetings!

Waldek Hebisch <de...@fricas.math.uni.wroc.pl> writes:

> On Fri, Feb 10, 2023 at 09:11:41AM -0500, Camm Maguire wrote:
>> Greetings!
>>
>> Might I please be granted git access to maintain the gcl/fricas
>> interface?
>>
>
> Of course. What is your Github id?
>

Great! cammgh

> BTW: After fixing issue with vanishing error messages (caused
> by old GCL specific code) with enough memory I now get:
>
> >> System error:
> Condition in SYSTEM::GCL-TOP-LEVEL [or a callee]: INTERNAL-SIMPLE-ERROR: File
> #p/mnt/lv0/fricas/axp8/fr-build326/src/algebra/CACHSET.NRLIB/CACHSET has been c
> ompiled for a restricted address space,
> and can no longer be loaded in this heap.
> You can recompile with :large-memory-model-p t,
> or (setq compiler::*default-large-memory-model-p* t) before recompiling.
>
> FriCAS may load new algebra code essentially at arbitrary time
> and potentially may allocate quite a lot of memory before load.
> Does it mean that FriCAS should do
>
> (setq compiler::*default-large-memory-model-p* t)
>
> for all loadable compilations?

Glad to see this got some airtime.

This is an option should you wish to use it. There is a modest
performance penalty, but you have complete freedom of where you load
code within a 64bit address space. Please be advised that at the moment
this option is only enabled and tested on amd64.

Alternatively, you can either

1) early in your image, or right before save-system

(setq si::*code-space* (make-array NNNNNNNNN :element-type 'character :static t)

where you have in advance estimated NNNNNNNNN to be sufficient for your
future loads.

2) do all your loads in a fresh image with optimal space utilization

(setq si::*optimize-maximum-pages* nil)

and then unset this before save-system.

Option 1) seems practical in other applications.

Unfortunately, and unlike memory range restricted relocs which can be
'fixed' at load time using veneers, the code produced by the various gcc
'memory models' is permanently unusable outside its designated memory
space.

Take care,