Re: OONSTD: Alias-free arrays

Gabriel Dos Reis (Gabriel.Dos-Reis@dptmaths.ens-cachan.fr)
Fri, 17 Jul 1998 11:11:53 +0200 (MET DST)

>>>>> «Todd», Todd Veldhuizen <tveldhui@seurat.uwaterloo.ca> wrote:

Todd> Gabriel Dos Reis wrote:
ERT> If computer architecture evolves to favor a different representation,
ERT> all the application programs that rely on access to the underlying
ERT> representation would suddenly become obsolete.
>>
>> I think it is a trivial statement that there cannot be a universal
>> matrix representation. Given that, one needs an alias-free 1D
>> array. For one dimensional array, valarray<> is good enough. I do see
>> valarray<> as a fondamental building block. I don't consider
>> valarray<> in the same way as string. I expect compiler writers to
>> follow the standard wording.

Todd> Having the NCEG "restrict" keyword would be more useful
Todd> than a built-in alias-free array class like valarray<>.

What is needed for an alias-free array like valarray<> is an efficient
implementation of BLAS-1. The standard specifications were weakened to
allow implementers to do so.

Todd> The restrict keyword has apparently been adopted into the C9x
Todd> standard, so hopefully it will become part of C++ in the future.

AFAIK it was first proposed in the C++ committee who rejected it.

Todd> Already several C++ compilers support it (Cray,KAI C++,SGI).

Todd> Btw, if you're interested in what the fuss is over aliasing
Todd> and restrict, there is some material which explains why aliasing
Todd> can cause poor performance: see pp. 53--56 of the "Techniques
Todd> for Scientific C++" slides available from
Todd> http://seurat.uwaterloo.ca/blitz/papers/

The problem isn't that I don't know aliasing side-effects on code
performance. I *am* aware of the problem.

BTW, C9x chooses to diverges from C++ and this situation is unlikely
to revert in the future.

Best wishes,

-- Gaby