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
