Is there support for a user defined scratch memory pool

[stgeke]

Many applications use an internal memory pool (scratch space). It would be great if this allocated memory could be recycled by SUNDIALS (e.g. for storing the Krylov basis array etc.) to lower the overall memory footprint.

[drreynolds]

The majority of memory used in SUNDIALS comes from the vectors themselves. As such, in collaborating with applications we have frequently implemented custom vectors that get their memory from a pool. This generally isn't difficult, since you can clone an existing N_Vector implementation and replace all memory allocation/deallocation to instead work with your pool. Would this kind of thing work for you, or are you asking for a general memory pool API that users can code to?

Regarding a general API -- have you looked at our recent SUNMemory API? It should certainly allow for this kind of thing with GPU-based memory allocation (@balos1 or @gardner48 can comment more directly on that).

[stgeke]

Let me be more precise. We want to recycling our internal scratch memory pool. I don't see how a custom N_Vector will help here. There will be vectors with persistent (e.g. state vector + history) and temporary (Krylov basis) data. Scratch memory (shared between different codes) can only be used for the latter type. Am I missing something?

[drreynolds]

I think I understand. Currently, SUNDIALS allocates all of its Krylov subspace vectors at initialization to improve performance (as compared to repeated allocation/deallocation). You worry that this unnecessarily increases the memory footprint, since those vectors could instead utilize temporary scratch space, space that could also be used in other areas of the code when the linear solver is inactive?

Is the recommendation that we implement a SUNDIALS-wide memory pool, and then we could convert module-specific memory allocations to instead check memory in/out of that pool when it is needed?

[stgeke]

Yes, adding a scratch memory pool within Sundials could help to reduce memory footprint. However my request is slightly different. I want to be able to pass a user defined scratch space to Sundials. This way the scratch memory can be shared between application code and Sundials provided it's big enough to make both codes happy.

[drreynolds]

Got it. I'll discuss this with the rest of the team. I don't recall us ever discussing this before, but I agree that it could certainly help in memory-limited environments (e.g., GPUs).

[stgeke]

Any news?

[balos1]

@stgeke We have had internal discussions on what may be done about this, but we do not currently have the bandwidth to implement anything in the near-term.