Re: [Boost-bugs] [Boost C++ Libraries] #4034: better vector/matrix assignment (or initialization)

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #4034: better vector/matrix assignment (or initialization)
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-04-11 14:41:04

#4034: better vector/matrix assignment (or initialization)
------------------------------+---------------------------------------------
 Reporter:  guwi17            |       Owner:  guwi17      
     Type:  Patches           |      Status:  new         
Milestone:  To Be Determined  |   Component:  uBLAS       
  Version:  Boost 1.42.0      |    Severity:  Optimization
 Keywords:  assigment         |  
------------------------------+---------------------------------------------

Comment(by cassioliandre@…):

 Nice job!
 I want to make few comments I hope that will be useful:

  * I found sometimes misleading the plain sintax:
 {{{
 #!C
 matrix<double> A(3,3);
 A <<= 1,2,3,4,5,6,7,8,9;
 }}}

 and in any case too many modificators may give rise to confusion and code
 mess. Why do not use the column_adaptor and row adaptor to explicitly
 insert cols and rows?
 {{{
 #!C
 matrix<double> A(3,3);
 //sorry for the non-standard syntax....
 row_adaptor(A,0) <<= 1,2,3;
 row_adaptor(A,1) <<= 4,5,6;
 row_adaptor(A,2) <<= 7,8,9;
 }}}

 the use of new_col and next_row is nice, and I might say in my opinion the
 plain traversing should be avoided, at least if no performance issues
 arise. The use of BOOST_UBLAS_DEFAULT_ASSIGN_BY_COLUMN define is not as
 clear as a many people might think. Instead, if traversing is needed, an
 explicit manipulator can do the trick.

 I do not think that assuming row_traversing by default is a clean and safe
 policy. I 'd rather imagine no default policy and explicit control by the
 user. The same applies to the wrapping.

 Another suggestion might be the inserte based syntax proposed for the
 MTL4:

 {{{
 #!C
 matrix<double> A(3,3);
 row_inserter row_ins(A);
 //sorry for the non-standard syntax....
 row_ins(0) <<= 1,2,3;
 row_ins(1) <<= 4,5,6;
 row_ins(2) <<= 7,8,9;
 }}}


  * performances are not equivalent to the standard assignement as claimed.
 I've played a little bit with the g++ compiler (version 4.4.3 with boost
 1.42) with my old intel centrino laptop and the results show a loss of
 performance between 13%  to 1566.67%, depending on the test and the
 optimization options (from -DNDEBUG only to -DNDEBUG -O3 -ftree-vectorize
 -funroll-all-loops).

 From my point of view, it sounds strange that performances could decay in
 such way, for the containers are created of the right size and no resizing
 take place (as for push_back operations). I can't see at the moment what
 might cause such overhead, but a code profiling might help.
 Forcing a more aggressive compilation helps, but I deep understand might
 be a good starting point to work out some hidden problems.



 By the way, it looks very promising! And indeed I do appreciate the idea
 of a set of static manipulators , possibly faster than the normal ones.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/4034#comment:5>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.