Boost logo

Ublas :

From: Michael Stevens (mail_at_[hidden])
Date: 2005-06-22 05:14:42

On Monday 20 June 2005 11:44, Ian McCulloch wrote:

> A global switch like that would be a mistake, IMHO. It would make it
> impossible to combine uBLAS functions from different sources while sill
> retaining performance, and force people wanting to write portable code to
> ALWAYS use either alias() or noalias() on every expression.

Agreed. The ability to combine uBLAS functions from different sources is
fundamental to me.

> However, something that might be useful is a global option to force alias()
> to be always on (ie, force 'safe' execution, even if noalias is specified),
> for debug checking.

Interesting idea. Something like BOOST_UBLAS_CHECK_NOALIAS perhaps?

> Perhaps it would be better to move the alias policy into the containers?
> The way I see it, you can think of an expression such as
> Vector x,y;
> Matrix M;
> x += M*x + y;
> in two ways:
> As an array expression, it is essentially a shorthand for
> for (i = 0; i < N; ++i)
> {
> x[i] += inner_prod(M[i], x) + y[i];
> }
> here the aliasing problem is obvious.
> Alternatively, if you view it as an expression over a ring (or R-module, or
> whatever), you would expect it to behave the same way as if x,y,M were
> simple numbers, and x += M*x + y should 'just work'.

Agreed. Two different way of view the problem.

> So, how about
> Vector<double> x; // default: forces 'safe' handling of aliases
> Vector<double, noalias> y; // fast: user takes responsibility for aliases

Syntacticly this is elegant but allowing container semantics to change is bad!

In generic code this brakes your portable code criteria. For example

template <class V>
multA (V& l, const V& r)
        l = prod (A, r);

Without knowing it's implementation it is impossible to know if 'multA (y, y)'
is correct.

> These would be roughly analagous to C99 restricted and non-restricted
> arrays,
> double x[];
> double y[restrict];
> in their expression semantics.

Although both vary the semantics I think C99 has an advantage over uBLAS in
this case. The restrict arrays only effect the semantics of a few aliased
pointer operations. uBLAS has to deal with the lvalue aliases.

A separate topic. It would be interesting to how much optimisation a compiler
of C++ with 'restrict' could gain when compiling uBLAS.
It would be easy in uBLAS to enforce 'restrict' internally and I suspect it
would help optimise expression evaluation a lot.