Boost logo

Ublas :

From: Michael Stevens (mail_at_[hidden])
Date: 2005-06-02 13:50:29

On Thursday 02 June 2005 18:00, christopher diggins wrote:
> ----- Original Message -----
> From: "Michael Stevens" <mail_at_[hidden]>
> >> That would definitely explain it and would be consistent the differences
> >> are so great between my old Celeron and Stefan's Pentium 4 which have
> >> wildly different sized caches.
> >
> > I don't believe the differences will be explained by you processors. I
> > suspect
> > there is something in how you are building the code. Is NDEBUG defined?
> Yes.
Makes no sense. Did you see Max's AthlonXP and P4 results posted yesterday.

> >> However, the question then become why would the operators be implemented
> >> so
> >
> > naively?
> >
> > If this is related to the aliasing issue then sadly the answer is that
> > finding
> > variable alias at compile time is out of the scope of what C++ can easily
> > do.
> > If you don't like tmp.plus_assign( v) you can use
> > noalias(tmp) += v;
> How is aliasing an issue for the +=/-= operations? Both should work fine
> even if the rhs is an alias for lhs. Is there any reason not to implement
> += as

I was talking about all operator in general. += and -= can be specialised for
the case where LHS and RHS are of identical type. In this case no aliasing
can occur. uBLAS already makes this specialisation for operator= in the same

If you are interested have a look at the assignment definitions in the in the
vector class. Of course any such change would need to be propagated to all
container types.


Michael Stevens Systems Engineering
Navigation Systems, Estimation  and
                 Bayesian Filtering