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.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:02 UTC