For this update, I would not be using GMP routines which perform memory allocation.
-- Raul On Tue, Oct 24, 2023 at 6:40 PM Henry Rich <[email protected]> wrote: > > The problem with using jtgafv was that you had to have GMP pass in jt. > > hhr > > On 10/24/2023 5:21 PM, Raul Miller wrote: > > Ah.. > > > > I was planning on using J's memory allocation routines (perhaps jtgafv?). > > > > Those libgmp low level functions are low-level functions which do not > > perform any memory allocation. For example: mpn_add_n adds two > > integers but requires memory allocation to be performed elsewhere. > > > > This is what would allow us (me) to use J's memory allocation routines. > > > > I hope this makes sense. > > > > And, I guess I should dive in and try something. If nothing else, to > > see what breaks... (I've made some small preparatory experiments, but > > I could obviously do a lot more.) > > > > -- > > Raul > > > > On Tue, Oct 24, 2023 at 1:44 PM Henry Rich <[email protected]> wrote: > >> You referred to a page on low level functions. I don't see how it applies > >> to allocation. > >> > >> hhr > >> > >> On Tue, Oct 24, 2023, 4:15 PM Raul Miller <[email protected]> wrote: > >> > >>> I've lost track of the thread here. > >>> > >>> Could you expand your question? > >>> > >>> Thanks, > >>> > >>> -- > >>> Raul > >>> > >>> On Tue, Oct 24, 2023 at 11:08 AM Henry Rich <[email protected]> wrote: > >>>> I don't see a memory allocator among the functions. How does this page > >>> help > >>>> with allocations? > >>>> > >>>> hhr > >>>> > >>>> On Mon, Oct 23, 2023, 6:10 PM Eric Iverson <[email protected]> > >>> wrote: > >>>>> I think gmp has proven itself and the cleanup you suggest would be > >>>>> worthwhile. > >>>>> > >>>>> On Sun, Oct 15, 2023 at 11:12 AM Raul Miller <[email protected]> > >>>>> wrote: > >>>>> > >>>>>> Some time ago, Elijah Stone pointed out that using > >>>>>> https://gmplib.org/manual/Low_002dlevel-Functions we could use J's > >>>>>> memory management routines directly, without having to deal with > >>>>>> libgmp's "exit the program if the library can't allocate memory" > >>>>>> behavior. > >>>>>> > >>>>>> This seems like it would be a good thing for us. When completed, we > >>>>>> could eliminate the memory pool currently used when handling extended > >>>>>> values, and we could also relax the current limit placed on the > >>>>>> magnitude of extended values. > >>>>>> > >>>>>> But changing everything all at once is a good way to never get > >>> started. > >>>>>> So, it's worth thinking about how we could organize this kind of > >>> effort. > >>>>>> Currently, the code is partitioned in three chunks: libgmp itself (or > >>>>>> mpir on windows), the jgmp.h/jgmpinit.h glue, and macros defined in > >>>>>> jgmp.h which are used in most of the rest of the system. (There's > >>> also > >>>>>> a few direct calls to libgmp functions in k.c, v2.c, vq.c, vx.c and > >>>>>> wn.c) > >>>>>> > >>>>>> So, conceptually speaking, we could implement workalikes for these > >>>>>> macros (things like XaddXX() which rely on the lower level mpn_ > >>>>>> functions instead of the problematic mpz_ / mpq_ functions. (We could > >>>>>> replace the direct calls with suitable macros, along the way. (Or, if > >>>>>> there's cases where there's really a significant performance > >>>>>> advantage, we could replace them with suitable direct calls to the > >>>>>> memory management routines and mpn_ functions. But this seems > >>>>>> unlikely.)) > >>>>>> > >>>>>> The trick would be allowing XNUM and RAT values whose memory was > >>>>>> allocated via libgmp to coexist with XNUM and RAT values whose memory > >>>>>> was allocated using J's memory manager. The details here are a bit > >>>>>> annoying, but fundamentally we've already provided for this. > >>>>>> > >>>>>> Basically, the distinction matters when we free the memory. And, that > >>>>>> decision is based on FHRHISGMP==AFHRH(x) vs FHRHISGMP!=AFHRH(x) in > >>>>>> jgmp.h and jgmpinit.c > >>>>>> > >>>>>> ----------------------------------------------- > >>>>>> > >>>>>> So.. it seems to me that if we created a parallel glue rig -- maybe > >>>>>> jgmpn.h -- we could start migrating functionality to the mpn_* family > >>>>>> of functions and J's "native" memory management. XaddXX() seems like > >>>>>> the place to start. > >>>>>> > >>>>>> I would need to figure out how to deal with the "realloc" cases where > >>>>>> the amount of memory required for a calculation (like multiply or > >>>>>> format) might be larger or smaller - perhaps significantly larger - > >>>>>> than the memory needed to represent the result. > >>>>>> > >>>>>> But, once started, the work could proceed gradually. As long as the > >>>>>> primitives continue to function, users mostly wouldn't notice the > >>>>>> changes. (And, ok, that sounds discouraging. But hopefully the end > >>>>>> result would be worth it.) > >>>>>> > >>>>>> Thoughts? > >>>>>> > >>>>>> My thought is that this kind of code cleanup seems worthwhile. > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> -- > >>>>>> Raul > >>>>>> > >>> ---------------------------------------------------------------------- > >>>>>> For information about J forums see > >>> http://www.jsoftware.com/forums.htm > >>>>> ---------------------------------------------------------------------- > >>>>> For information about J forums see http://www.jsoftware.com/forums.htm > >>>>> > >>>> ---------------------------------------------------------------------- > >>>> For information about J forums see http://www.jsoftware.com/forums.htm > >>> ---------------------------------------------------------------------- > >>> For information about J forums see http://www.jsoftware.com/forums.htm > >>> > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
