|
|
Ublas : |
From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-06-14 21:31:01
----- Original Message -----
From: "Ian McCulloch" <ianmcc_at_[hidden]>
To: <ublas_at_[hidden]>
Sent: Tuesday, June 14, 2005 9:55 PM
Subject: Re: [ublas] Aliasing for += and -=
> christopher diggins wrote:
>
>>> 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.
>
> What does it mean for the library to *use* aliases? How does the library
> know whether arguments are aliases (except in some special cases) ?
It doesn't, but a matrix and vector library does not have to allow aliasing
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.
>
> What do you mean by "never alias anything"? How can the *library* choose
> that?
As gunter pointed out things like:
r1 = project( x, range(0,4) )
r2 = project( x, range(2,6) )
create aliases. This is a choice made by the library. If the library
operations never create aliases, then the basic operations can be more
efficient.
>>> 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.
>
> Now I am lost: I thought the (often) superfluous copy that uBLAS performs
> is
> what you were arguing against?
I am differentiating between the blas subroutines and the ublas library.
Aliasing is a technique of allowing memory to be shared, which is supposed
to save superflous copies in some circumstances (but evidently not many).
This is the only reason I can understand for using aliasing in the first
place.
Christopher Diggins
http://www.cdiggins.com