Memory efficient implementation, holding a single plan?

[chaithyagr]

I was curious if you guys had any plans to support for a more memory efficient version of NUFFT which does both forward and backward while not maintaining 2 plans (which involves 2 versions of the same trajectory, and cuFFT work areas.)
Does this seem doable in foreseeable future?

[ahbarnett]

Hello Chaithya, This is a good idea. My initial reaction is we should strongly consider it. We could have a single plan for either t1 or t2. This is because almost all aspects of the plan are the same: 1) the binsort, 2) the FFT (or CUFFT) plan, 3) the phiHat deconvolution coefficients, 4) the batching. So, the question is, how would the user then communicate in the exec stage whether t1 or t2 is wanted? One idea is that they could safely change the type in the plan, to "switch from t1 to t2" with zero cost (just change plan.type) - in fact, what stops the user doing that right now? (at least in C++ interface?) I didn't think of this since I didn't realize that the plan was a big RAM cost ... (sounds like it is). Let's hash out a proposal here. Best, Alex

…

On Mon, Sep 23, 2024 at 7:56 AM Chaithya G R ***@***.***> wrote: I was curious if you guys had any plans to support for a more memory efficient version of NUFFT which does both forward and backward while not maintaining 2 plans (which involves 2 versions of the same trajectory, and cuFFT work areas.) Does this seem doable in foreseeable future? — Reply to this email directly, view it on GitHub <#566>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNZRSRIISUQYA3KI7XHDNLZX76VTAVCNFSM6AAAAABOV46C4GVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXGIZDKNJUGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- *-------------------------------------------------------------------~^`^~._.~' |\ Alex Barnett Center for Computational Mathematics, Flatiron Institute | \ http://users.flatironinstitute.org/~ahb 646-876-5942

[chaithyagr]

So, the question is, how would the user then communicate in the exec stage
whether t1 or t2 is wanted?

I would recommend we have 2 things as input for the exec: 1) FFT direction, 2) Type of operation.
This will cover 4 general cases...
For backward compat, we can always make wrappers such that these are appropriately added into the calls if they are already specified during the plan creation.

One idea is that they could safely change the type in the plan, to "switch from t1 to t2" with zero cost (just change plan.type) - in fact, what stops the user doing that right now? (at least in C++ interface?)

I didnt know it was that simple. Can we add support for this on Python ? I can write the necessary support..

[chaithyagr]

I dont think it is only the memory inefficiency here, even the creation of 2 plans have associated redundancy in sorting and kernel estimations etc... Right? This matters a lot for learning some sampling pattern for example.