Move constructors

Ideas and suggestions for features that could (or should) be added to the CML.

Move constructors

Postby qbprog » Mon Jun 01, 2015 10:48 am

It would be nice if CML adds support to move constructors and assignment operators, so matrixes (and other classes) can be moved around instead of just copied!

Qb
qbprog
 
Posts: 6
Joined: Mon May 09, 2011 9:11 am

Re: Move constructors

Postby dnave » Mon Jun 01, 2015 1:41 pm

Hi Qb,

If you haven't tried it already, CML2 has move constructors. It isn't feature complete just yet, as I haven't completed the port of the mathlib code to CML2, but it is usable. Note, though, that move constructors don't do much for dense vectors and matrices unless the elements themselves are expensive to copy, but cheap to move. No matter what, if you are computing M=A*B, the elements of M have to be copied from the result of A*B. Ideally, the compiler's (N)RVO and constructor elision optimizations will make this copy as fast as possible, but this isn't always the case.

If you are working with CML2, and are seeing performance problems there, please let me know. It's a complete rewrite of the CML API to C++11 (with support for VS2013's lackluster implementation), so there are many opportunities for me to miss optimizations.

Keep me posted.
Cheers,
Demian
dnave
 
Posts: 113
Joined: Fri Jun 29, 2007 12:46 am
Location: Pittsburgh, PA

Re: Move constructors

Postby qbprog » Mon Jun 01, 2015 2:01 pm

Hello Demian!
nice to know that there is a CML2 in development! Where are you developing it? I cannot even reach the sourceforge page by now (403 error).

Actually I just looked for move constructor to avoid matrix -> matrix copies, which is something I frequently do. I didn't expect to have an extreme move optimization during operations but only for common copy cases.

Thanks for the informations!
Qb
qbprog
 
Posts: 6
Joined: Mon May 09, 2011 9:11 am

Re: Move constructors

Postby dnave » Mon Jun 01, 2015 2:08 pm

Oops, I broke something. I will see what I did. The source is over at GitHub now, though:

https://github.com/demianmnave/CML

As for move constructors, as I mentioned, they won't help in those common cases. If you are doing A = B, the elements of B have to be copied to A no matter what. Even if you are passing matrix arguments by value instead of by reference, the move constructor can't eliminate the copy. You have to get the elements from A into B, and that necessarily requires a copy.

Does this help, or am I not understanding the problem?

Cheers,
Demian
dnave
 
Posts: 113
Joined: Fri Jun 29, 2007 12:46 am
Location: Pittsburgh, PA

Re: Move constructors

Postby qbprog » Mon Jun 01, 2015 3:08 pm

Yes of course, when you have to copy it's correct to copy and not to move.

I was meaning something like

A = std::move(B)

or
A = function_that_returns_B();

(of course in the latter case there may be other compiler optimizations)

When there are temporary objects, move constructors/assigments are useful!

Qb
qbprog
 
Posts: 6
Joined: Mon May 09, 2011 9:11 am

Re: Move constructors

Postby dnave » Mon Jun 01, 2015 3:47 pm

So, in the case of A = std::move(B), there is no benefit to the move() unless the elements of B are themselves cheaper to move than to copy. For instance, if the elements of B are contained in a dynamically-allocated array, and A and B are just wrappers around the pointer to an array of elements, then it is cheaper---in general---to move the pointer from B to A than it is to copy the elements from B to A. The case where this may not be true is if A already has an allocated array of elements that then has to be delete'd because it is taking over B's array, and A and B are small-ish vectors or matrices. Then, it is quite possible for the deallocation of A's array to be more expensive than simply copying the elements of B into A.

The case is about the same for the second example, except that compilers typically implement "return value optimization" (RVO) and/or "named return value optimization" (NRVO), which obviate the need for a move constructor in some instances. But, note how what I said above is true for the return value, also. If function_that_returns_B() ends with "return std::move(B)", this basically has the same effect as A = std::move(B), and thereby matches your first case.

I guess what I am saying is that move constructors don't always lead to more efficient temporaries. And now I'm actually thinking it could interfere with (N)RVO---I need to look into that...

Am I still missing your point?

Cheers,
Demian
dnave
 
Posts: 113
Joined: Fri Jun 29, 2007 12:46 am
Location: Pittsburgh, PA

Re: Move constructors

Postby qbprog » Mon Jun 01, 2015 7:01 pm

no no, that's exactly my point!

thanks for the details and the dicussion, I will investigate the possible benefits with a little more detail.
Actually I was looking to (possibly) optimize the usage of some matrix_44 objects which get copied around a little too much, but after your description I'm not even sure if it's data is dynamically allocated or not! Tomorrow I will check it and if it's allocated on the heap the move constructor may bring some optimizations

Actually, as you pointed, my rule of thumb is that if data pointers can be swapped I implement move constructors, else I stick with copies!

Byee :)
Qb
qbprog
 
Posts: 6
Joined: Mon May 09, 2011 9:11 am

Re: Move constructors

Postby dnave » Tue Jun 02, 2015 2:28 am

:-) Please let me know if you have any questions, I am happy to help.

Have fun!
Demian
dnave
 
Posts: 113
Joined: Fri Jun 29, 2007 12:46 am
Location: Pittsburgh, PA


Return to Feature Requests

Who is online

Users browsing this forum: No registered users and 1 guest

cron