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-12 00:49:50

#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 nasos_i@…):

 Andrea,

 I suppose this debate will go on for a while, as I feel that people are
 divided in the explicit or implicit traversing options :). Anyway both can
 be implemented so I suppose it is a matter of choice from Gunter and
 David, or from the overall popularity in the mailing list or here.

 > Why do not use the column_adaptor and row adaptor to explicitly insert
 cols and rows?

 This can be achieved in a way as for example:

 {{{
     matrix<double> m;
     matrix_row<matrix<double> > mr (m, 0);
     mr <<= 1,2,3;
     std::cout << m << std::endl;
 }}}

 I think there may be the need for a few more overloads to achieve what you
 propose in general. What do you think of just using the matrix proxies?
 What do others think?

 > in my opinion the plain traversing should be avoided, at least if no
 performance issues arise .... 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
 It indeed may be safer and I think no performance issues arise from that.
 I am not personally convinced though that the safety penalty in stake is
 that big to drop such convenience. Another consideration for uBlas also is
 the way people look into it for the first time, I believe an interface
 that makes sense for the first time user, with certain customisation
 options for the most advance would turn to be beneficial.

 Anyway a simple redirection will disable the assignment without an
 explicit definition of the traverse and wrap policies.

 > performances are not equivalent to the standard assignement as claimed

 Unfortunately on my intel core 2 duo laptop (like 2 years old) I see no
 statistically significant difference in performance. Other times the
 classical assignment is faster and other times the assigner assignment is
 faster (this difference ranges from 0 to 10% both ways). I will look in
 the assembly code and maybe try to compile on other machines too.

 My understanding though is that for very small containers, and for certain
 compilers or architectures, there maybe the need of creating empty objects
 (like the ones used for certain manipulators), that may still require an
 1-byte constructor to be invoked. If you see such a difference maybe
 something like that is happening with the specific setup. I tried to avoid
 such a problem by using function based manipulators (like std::endl), but
 because of the generally more complicated nature of the assigner objects
 relative to streams, a good design could not be achieved. After all my
 benchmarks did not signify that this was necessary. Will look more into
 that and if somebody has something to input (like architectures or
 compilers that this is the case) I will really like to look into it.

 Also what is the performance penalty (negative or positive, the last test
 in the benchmarks gives you for full optimization? This is supposed to be
 very light weight).

 Thanx for the very constructive input!

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