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
case.

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

-- 
___________________________________
Michael Stevens Systems Engineering
Navigation Systems, Estimation  and
                 Bayesian Filtering
    http://bayesclasses.sf.net
___________________________________