Re: [ublas] Move Semantics

Subject: Re: [ublas] Move Semantics
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2009-09-07 11:13:34

On Wed, Sep 2, 2009 at 2:29 PM, Gunter Winkler <guwi17_at_[hidden]> wrote:

>  > Also, I see that this is native to MTL:
> >
> http://www.osl.iu.edu/research/mtl/mtl4/doc/matrix_assignment.html#move_semantics
> >
> in ublas the move semantics is partially available:
>
> A.assign_temporary( same type as A )
>
> this is implemented by swapping the internal storage objects.
>
> Awesome.

> if B in very large than it is already very expensive to compute inv(B).
> In order to optimize this we had to modify the inv() method to return an
> expression template instead of acutally computing the result. Then the
> computation is deferred until the assignement to A is executed. However
> this only helps if we can easily compute the rhs expression element by
> element.
>
> Yup.  And as you say, that isn't the case here (or in many places where we
end up using the bindings...)

>  > If this pattern is not usable yet, any idea of when it would be?
>
> for inversions of general matrices I see no option except the usual
> "decompose" and "solve" strategy which must be coded explicitly.
>
> True, but somehow the MTL4 guys have move semantics working so that you can
return the matrix expression...  Might be worth checking out their
solution.
http://www.osl.iu.edu/research/mtl/mtl4/doc/matrix_assignment.html#move_semantics

So let me throw out the following idea:
1) People really want functional style returns, for all of the usual
reasons.
2) I think that there are a lot of people using compilers with C++0X
support, especially in numerics.  Intel 11.1 supports auto, decltype, and
rvalue references.  GNU already has it.  And MSVC 2010 with have all of
these as well.  I think it is reasonable to have some features that
selectively turn features on based on compiler support.
3) Boost::move seems to be getting there...
http://svn.boost.org/svn/boost/sandbox/move/libs/move/doc/html/index.html
so it might even be possible to get stuff working with C++03.

So, with all that said... is a possible solution to the return value thing
to implement rvalues constructors, etc. for the matrix and vector
expressions? http://svn.boost.org/svn/boost/sandbox/move/libs/move/doc/html/move/implementing_movable_classes.html#move.implementing_movable_classes.copyable_and_movable_cpp0x

Could we have a preprocessor instruction that generates the rvalue
implementations?  Can the assign_temporary() be used here to make the code
easy?

If the assign_temporary only works for expressions of the same type, it
might not work so well, but thought I would throw out the idea.  This
feature would be almost as important as the operator* overloads for
usability.

-Jesse