[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fricas-devel] FriCAS CheckBench and errors with different CL flavor

From: Camm Maguire
Subject: Re: [fricas-devel] FriCAS CheckBench and errors with different CL flavors
Date: Sat, 11 Feb 2023 12:48:47 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)


Waldek Hebisch <devel@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

Take care,

> -- 
>                               Waldek Hebisch

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]