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

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-06-14 20:46:35

----- Original Message ----- 
From: "Ian McCulloch" <ianmcc_at_[hidden]>
To: <ublas_at_[hidden]>
Sent: Tuesday, June 14, 2005 7:57 PM
Subject: Re: [ublas] Aliasing for += and -=

> christopher diggins wrote:
>
>> ----- Original Message -----
>> From: "Robbie Vogt" <r.vogt_at_[hidden]>
>> To: "ublas mailing list" <ublas_at_[hidden]>
>> Sent: Tuesday, June 14, 2005 6:58 PM
>> Subject: Re: [ublas] Aliasing for += and -=
>>
>>
>>> Hi all,
>>>
>>> Ian McCulloch wrote:
>>>
>>>>FWIW, I have pretty much come to the conclusion that noalias should be
>>>>the default, but my reasons are (1) I think it IS easy, in *most* cases,
>>>>to determine when incorrect aliasing occurs - I guess Fortran 
>>>>programmers
>>>>learn very quickly, and (2) even if there is an aliasing problem, it is
>>>>not
>>>>necessarily most efficient to copy the final expression.  There are some
>>>>cases where making a copy of a subexpression would suffice.  And (3) in
>>>>debug mode, the assignment operators can compute the expression both 
>>>>ways
>>>>and assert that the result is the same.
>>>>
>>>>
>>> I would like to second all of Ian's points above.  I always thought it a
>>> strange decision in the design of uBLAS to go the "safe" route at the
>>> expensive of performance, particularly in light of common practice in
>>> C/C++ library (and language) design to trust the programmer (eg.
>>> std::copy can also have aliasing issues if the programmer isn't
>>> careful).  I also believe a trust-the-programmer approach would have
>>> lead to far simpler code to maintain and enhance.
>>>
>>> Alas, as Christopher points out, this type of fundamental change in
>>> design would require an enormous effort to re-implement the entire
>>> library and would probably no longer be uBLAS as we know it.  I have
>>> been inclined in the past to suggest a complete rethink on the design
>>> and a "uBLAS 2," but hopefully MTL3 will fill this role.  Possibly our
>>> best plan of attack is to get more involved in the development of the
>>> new MTL so that it is brought to life as quickly as possible.
>>>
>>> Regards,
>>> Robbie.
>>
>>
>> I still don't understand why aliasing is used in the first place. Nobody
>> has bothered to explain how it warrants the additional complexity and
>> unsafety and performance penalty.
>
> I don't think the tradeoff's work that way.  Whether aliases appear in an
> expression depends purely on how the user writes it,

It also depends on whether the library actually uses aliases in the first 
place.

>  the question is
> whether the library gets the correct answer or not.  The choices are:
> always make a copy of the right-hand-side before assigning to the
> left-hand-side.  This will always give the correct answer, but at a
> performance cost.  This is the way uBLAS works.  OR never make a copy of
> the right-hand-side and require the user to handle potential aliasing
> issues.

Or never alias anything. Always correct and as I demonstrated, is more 
efficient than ublas for all of the basic operations.

> In both cases, the default can be overridden - in the former by
> providing an alternate syntax to perform the operation with a noalias
> assumption, and in the latter by choosing a different algorithm (eg, to
> copy backwards instead of forwards) or making an explicit copy.
>
> In one case, the default operation is slow and safe.  In the other, the
> default operation is fast and dangerous.  None of the choices is both
> unsafe and with a performance penalty.

Having a library which uses aliasing doesn't buy you anything except saving 
against the occasional superflous copy (which isn't a problem when using 
blas routines). My point is that the superflous copy is less common than the 
basic operation (like indexing, or scalar multiplication, or matrix 
addition, or matrix multiplication) which I showed alread was more efficient 
doing naively.

Christopher Diggins
http://www.cdiggins.com