Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No non-allocating mul! for CompositeMap #202

Open
junyuan-chen opened this issue Feb 25, 2023 · 2 comments
Open

No non-allocating mul! for CompositeMap #202

junyuan-chen opened this issue Feb 25, 2023 · 2 comments

Comments

@junyuan-chen
Copy link

junyuan-chen commented Feb 25, 2023

With the current implementation, mul! involving a CompositeMap 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 via mul!.

@junyuan-chen junyuan-chen changed the title No non-allocating multiplication for CompositeMap No non-allocating mul! for CompositeMap Feb 26, 2023
@dkarrasch
Copy link
Member

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 CompositeMaps 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.

@daanhb
Copy link

daanhb commented Mar 18, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants