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
