quil-lang / magicl

Matrix Algebra proGrams In Common Lisp.
BSD 3-Clause "New" or "Revised" License
230 stars 44 forks source link

loading `MAGICL/EXT-LAPACK` or `MAGICL/EXT-EXPOKIT` exhausts SBCL heap #204

Open mantacid opened 2 months ago

mantacid commented 2 months ago

Attempting to load the Lapack extension of the library causes the SBCL repl to run out of heap.

LAPACK REPL output:

This is SBCL 2.3.11, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (ql:quickload "magicl/ext-lapack")                                     
To load "magicl/ext-lapack":
  Load 1 ASDF system:
    magicl/ext-lapack
; Loading "magicl/ext-lapack"
..................................................
..................................................
..................................................
..............Heap exhausted during garbage collection: 0 bytes available, 16 requested.
        Immobile Object Counts
 Gen layout fdefn symbol   code  Boxed   Cons    Raw   Code  SmMix  Mixed  LgRaw LgCode  LgMix Waste%       Alloc        Trig   Dirty GCs Mem-age
  2      0      0      0      0  11349   1636   2770      5    453   1030     31      0     67    0.4   565980624     2000000   17341   0  1.0656
  3      0      0      0      0      0      0      0      0      0      0      0      0      0    0.0           0     2000000       0   0  0.0000
  4      0      0      0      0      0      0      0      0      0      0      0      0      0    0.0           0     2000000       0   0  0.0000
  5      0      0      0      0      0      0      0      0      0      0      0      0      0    0.0           0     2000000       0   0  0.0000
  6    763  16519  26487  18745    339    112      7      3      8     15      0      0     63    2.7    17442912     2000000      14   0  0.0000
  7      0      0      0      0   9793   1517   2086      4    443    867     59      0    111    0.5   485372192     2000000   14880   0  0.0000
Tot    763  16519  26487  18745  21481   3265   4863     12    904   1912     90      0    241    0.5  1068779472 [99.5% of 1073741824 max]
GC control variables:
   *GC-INHIBIT* = true
   *GC-PENDING* = true
   *STOP-FOR-GC-PENDING* = false
Collection trigger variables:
   dynamic_space_size = 1073741824
   bytes_allocated = 1068779472
   auto_gc_trigger = 621335187
   bytes_consed_between_gcs = 53687091
fatal error encountered in SBCL pid 4853 tid 4853:
Heap exhausted, game over.

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
(GC in progress, oldspace=2, newspace=7)
ldb> 

EXPOKIT REPL output:

This is SBCL 2.3.11, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (ql:quickload "magicl/ext-expokit")
To load "magicl/ext-expokit":
  Load 1 ASDF system:
    magicl/ext-expokit
; Loading "magicl/ext-expokit"
..................................................
..................................................
..................................................
..............Heap exhausted during garbage collection: 16 bytes available, 32 requested.
        Immobile Object Counts
 Gen layout fdefn symbol   code  Boxed   Cons    Raw   Code  SmMix  Mixed  LgRaw LgCode  LgMix Waste%       Alloc        Trig   Dirty GCs Mem-age
  2      0      0      0      0  11335   1650   2766      5    465   1051     31      0     67    0.4   566936000     2000000   17370   0  1.0653
  3      0      0      0      0      0      0      0      0      0      0      0      0      0    0.0           0     2000000       0   0  0.0000
  4      0      0      0      0      0      0      0      0      0      0      0      0      0    0.0           0     2000000       0   0  0.0000
  5      0      0      0      0      0      0      0      0      0      0      0      0      0    0.0           0     2000000       0   0  0.0000
  6    763  16519  26487  18745    339    112      7      3      8     15      0      0     63    2.7    17442880     2000000      14   0  0.0000
  7      0      0      0      0   9769   1517   2080      4    465    846     59      0    111    0.4   484509744     2000000   14851   0  0.0000
Tot    763  16519  26487  18745  21443   3279   4853     12    938   1912     90      0    241    0.5  1068872400 [99.5% of 1073741824 max]
GC control variables:
   *GC-INHIBIT* = true
   *GC-PENDING* = true
   *STOP-FOR-GC-PENDING* = false
Collection trigger variables:
   dynamic_space_size = 1073741824
   bytes_allocated = 1068872400
   auto_gc_trigger = 622511539
   bytes_consed_between_gcs = 53687091
fatal error encountered in SBCL pid 11457 tid 11457:
Heap exhausted, game over.

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
(GC in progress, oldspace=2, newspace=7)
ldb> 

AFAIK, the other extensions are able to be imported (albeit with other issues, like matrix multiplication being non-functional for some reason).

stylewarning commented 2 months ago

I think you're starting SBCL with just 1 GB of memory. It's not very much memory for the whole of SBCL + dependencies + memory needed to perform the compilation.

Can you start SBCL with more than 1 GB of memory?

sbcl --dynamic-space-size 4096

for 4 GB, if I recall correctly.

mantacid commented 2 months ago

starting it with 3GB fixes the issue. sorry for the unneeded report.

stylewarning commented 2 months ago

starting it with 3GB fixes the issue. sorry for the unneeded report.

No, thank you!

It would be good for us to document. We also plan to decrease the compilation burden a bit in the future. MAGICL takes way too long to compile for not as much benefit as we should be getting. :)