Open junyuan-chen opened 1 year ago
Yes, the current status is that you explicitly hook into the _compositemul!
machinery, which was introduced for exactly that purpose, when users know that they are dealing with CompositeMap
s and know an appropriate eltype of the intermediate storage arrays. It is somewhat isolated from the rest of the package because no other map type provides such an opportunity. After all, memory optimization has never been within the scope of this package, because it is in its generic form a very difficult task. Note, however, that _compositemul!
is covered by tests (and called explicitly), so it is "quasi-exported" and guaranteed to stay.
Might it be possible to "plan" the application of a composite map?
Similarly to plan_fft
and plan_fft!
, the plan could take an example vector, from which it could deduce the types of all intermediate vectors.
This might still prove to be difficult, but at least the logic of planning the application of a map can be separated from the map itself.
With the current implementation,
mul!
involving aCompositeMap
allocates an array for each intermediate step of the multiplications along the chain of maps. There are internal methods_compositemul!
and_compositemulN!
that accept intermediate arrays. However, they are not exposed to any exported public API and seem to be quite isolated from the rest of the package. Ideally, there should be some way to specify the preallocated arrays viamul!
.