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 <eric.b.iver...@gmail.com> 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 <rauldmil...@gmail.com> > 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
