Re: [ublas] Aliasing for += and -=

From: Michael Stevens (mail_at_[hidden])
Date: 2005-06-14 15:10:07

On Monday 13 June 2005 17:21, Gunter Winkler wrote:
> Am Montag, 13. Juni 2005 15:43 schrieb christopher diggins:
> > boost ublas performance, rows = 3, cols = 3, iters = 100000
> > benchmarking element_access(m1) 406 msec elapsed
> > benchmarking matrix_copy(m1, m2) 31 msec elapsed
> > benchmarking scalar_arithmetic(m1) 266 msec elapsed
> > benchmarking matrix_arithmetic(m1, m2) 2407 msec elapsed
> > benchmarking multiply(m1, m2, m3) 234 msec elapsed
> >
> > boost ublas performance, rows = 100, cols = 100, iters = 100
> > benchmarking element_access(m1) 390 msec elapsed
> > benchmarking matrix_copy(m1, m2) 0 msec elapsed
>
> zero time for copy?
>
> > benchmarking scalar_arithmetic(m1) 266 msec elapsed
> > benchmarking matrix_arithmetic(m1, m2) 796 msec elapsed
> > benchmarking multiply(m1, m2, m3) 3828 msec elapsed
>
> what compiler did you use? The cvs head of ublas is _very_ slow with
> gcc-3.3 but fast as usual with gcc-3.4. Can you post or mail the
> benchmark program? I'd like to check the times.
>
> > k-matrix is a matrix implementation where rows and columns are known
> > at compile-time. ultiplication was done using axpy_prod.
>
> Does that mean "everything constant"? Then the compiler could compute
> the result and the execution time would be zero.
>
> > matrix<int> m;
> > m *= 2;
> > m += m;
> > m[i][j] = 0;
> >
> > I can heare the chorus of screams, but you didn't using "noalias". In
> > real code whether something is aliased or not is not trivially known.
> > So it is not fair to use "noalias" in a straightforward comparion.
> > Furthermore I am comparing "out-of-the-box" performance for naive
> > users (the most common kind).
>
> I disagree. If you compare (peak) perfmance, you should use the best
> code, not the shortest.
>
> @all: Do you think, that it is possible to autodetect aliasing at
> compile time via the container_reference class?
>
> Should we add new overloads of += and co. to vector and matrix types:
>
> self_type & operator += (const self_type& rhs) {
>   plus_assign(rhs);
>   return (*this);
> }

This would also be my suggestion. For some container classes in can be made a 
little more general then self_type. We just need to ensure the the rhs is a 
similar container. For example vector has the following:
        template<class A2>          // Generic vector assignment without 
temporary
        BOOST_UBLAS_INLINE
        vector &operator = (const vector<T, A2> &v) {
            resize (v.size (), false);
            assign (v);
            return *this;
        }

The key thing is this needs to be propgated to all container types. I was 
hoping Christopher would submit a patch :-)

Michael