Support for immutable LinearSpace elements #1663
Conversation
|
Checking updated PR...
Comment last updated at 2024-12-03 17:16:00 UTC |
leftaroundabout
force-pushed
the
devel/inplace-calc-decision
branch
from
4d55811 to
4af9990
Compare
… operations are used.
…ntly in common use.
This allows a single point of entry for addition, multiplication etc., which is useful when these operations involve more decisions, like the planned in-place vs out-of-place distinction.
This is the underlying implementation behind several of the standard arithmetic operators like +. Previously, ODL would always force these to be evaluated with an in-place result, even though that has little benefit when no preallocated memory is used for this.
…division. Until now, ODL always switches to in-place style in the general wrappers, but this will change in the future because it does not play well with PyTorch. The new SupportedNumOperationParadigms feature would in principle allow declaring that the NumPy version supports _only_ in-place operations. That would probably work ok in practice, with much the same behaviour as the old version, but it could lead to strange problems when dealing with product spaces where some subspaces support only out-of-place. Since NumPy can do out-of-place just fine, it would be pointlessly dogmatic to prevent that.
The subsequently called `lincomb` etc. methods already have the logic for allocating `out` objects if the space desires, and doing it beforehand precludes using the out-of-place operations that are preferrable in e.g. PyTorch.
The previous implementation in terms of `_lincomb` precluded out-of-place implementations of the latter. It is also inefficient, and cannot well avoid unnecessary copies.
leftaroundabout
force-pushed
the
devel/inplace-calc-decision
branch
from
4af9990 to
1aa9221
Compare
Up until now, ODL has had a strong emphasis on carrying out operations in-place. This is similar to traditional application-specific software like solvers written in Fortran, even when the user writes code that looks more functional/declarative.
While this is in many instances a good tradeoff between high-level ease of use and low-level performance, it is not suitable for all use cases.
This pull request allows spaces to specify whether their elements can be handled as mutable or immutable objects, and/or which way is more appropriate. Based on this, the general arithmetic operations will either pre-allocate memory and use it in place, or give back results in a RAII- / move-semantics fashion.
I have tested that this works by confirming that the test suite succeeds also when (contrivedly) selecting
in_place = NumOperationParadigmSupport.NOT_SUPPORTEDforNumPyTensorSpace. Not sure whether it would make sense to include this into the test suite.The PR does not yet guarantee that operators and solvers follow the style indicated by
supported_num_operation_paradigms, though to some extend they inherit the behaviour of the arithmetic primitives.