|
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 ___________________________________