|
|
Ublas : |
Subject: Re: [ublas] Move Semantics
From: Gunter Winkler (guwi17_at_[hidden])
Date: 2009-09-02 14:29:24
Jesse Perla schrieb:
> Hi there,
> I am writing many routines where I would strongly prefer:
> matrix<double> f(const matrix<double>& in) to void f(const
> matrix<double>& in, matrix<double>& out )
> There has been a lot of discussion about this from the C++ groups:
>
> * The move library to support this in C++03
> * http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/
>
> 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.
> I don't understand expression templates well enough to know the
> current state in ublas, but is it possible to return large matrices in
> this way? For example, if I took the following code:
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?LU_Matrix_Inversion
> and had it return a matrix instead, would that give overhead for large
> matrices?
> Could I even nest it with no overhead in other vector expressions: e.g.
> matrix<double> C, B; //setup. Assume they are very large
> matrix<double> A = inv(B) + C;
>
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.
> 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.
Back to your original question:
in order to see how the expression templates work you should have a look
at vector_expression.hpp, e.g., class vector_binary. This class simply
holds the two operands and the operation to carry out. Right below this
class you see the implementation of the free functions operator+(),
operator-(), element_prod() and element_div() for vectors. The whole
magic is hidden in the iterators who should provide an optimal traversal
through both vectors. The actual computation is done in the
dereference() function (which simply calls functor::apply(xi,yi).
mfg
Gunter
>
> Thanks,
> Jesse
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ublas mailing list
> ublas_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: guwi17_at_[hidden]