lapackers

["Hatem Ltaief" <Hatem.Ltaief@kaust.edu.sa>]

Julien and Julie,
Thanks.
See some answers below.

On Apr 25, 2011, at 4:50 AM, Langou, Julien wrote:

> Hi Hatem, 
> 
> I am kind of confused with the first fix. (Conjugate TAU in xLARFX.)
> I think the proper way for all this to work is that you should conjugate 
> TAU not within LAPACK xLARFX but when you call xLARFX from 
> your application. ( !!! )
> 
> In other words, since we are dealing with elementary Householder
> reflections, using TAU means applying H, using CONJG(TAU) means
> applying the conjugate transpose of H. Note that a routine such as 
> DGEQR2 applies the conjugate transpose of a bunch of elementary
> Householder reflections H. (Note the elementary reflections themselves.)
> This is just a matter of conventions.
>       
> xLARFX and xLARF are supposed to be interchangeable. 
> Does your code work with xLARF and not with xLARFX?
Sure. LARFX has just to be seen as LARF (and not a driver routine like 
GEQR2). 
It is just a wrapper,
which will lead you to LARF call or the unrolled version.
So, in that sense, this is the user duty to transpose TAU.
And I guess this is the reason why it fails lapack testings.

> 
> OK, I have my son on one shoulder trying to read what I am typing.
> (He is doing pretty actually: "I have my son on one ?WHAT DADDY?)
:)

> 
> Will look at the flops saving trick later. But I am all in favor of that 
> one. 
> And there are a few other places where it is needed. And actually, I 
> personnally do not care for saving a few flops. But I care a lot for 
> avoiding
> to have to set V(1) to 1.0E+00 from the calling code. This is really 
> important
> to remove this from LAPACK. V(1) is supposed to be implicity 1.0E+00, 
> and we store in this place an entry of R. Having to set it to 1.0E+00
> is really a nightmare for the LAPACK code.
> 
> Because we have this V(1) = 1 statement all over the place, some of our 
> subroutines. I am thinking to DLARFT ... V is INPUT/OUTPUT because 
> of the V(1)=1 statement. And having a tile INPUT as opposed to INOUT
> is a big big big deal. DLARFT pollutes everything. See for example 
> DORMQR. DOMRQR is polluted by that.  in DORMQR, V one more time
> is INOUT whereas it should be only INPUT. 
> 
> So yes the fix if Hatem saves one, two, three flops but it is potentially 
> much more 
> important than that.
Indeed, the implications are much broader than saving a flop here
and there.

> 
> J.
> 
> BTW: RdVG says that LAPACK is not thread safe precisely for the
> reason above. We answered him that his statement was not correct. 
> He still claims this in conference. Our answer to him was that if he is 
> calling a routine (ORMQR) with a parameter flagged INOUT (V) with
> two distinct threads in parallel, he might need to stop coding 
> multithreading codes. 
same o same o.

Thanks,
Hatem


> 
> 
> 
> 
> On Apr 24, 2011, at 4:32 AM, Hatem Ltaief wrote:
> 
>> All,
>> There is a bug in this auxiliary routine of LAPACK.
>> This routine applies a single reflector V to a general dense block.
>> If V is of size less than 11, the routine provides an unrolled
>> way of computing the operations (for eventual compiler optimizations).
>> The bug is in single and double complex for the case "LEFT".
>> The conjugate of TAU needs to be used rather than TAU itself when
>> [c,z]larf are called (if size of V is of size > 11) or when the unrolled
>> version is selected (if size of V is <= 11).
>> 
>> Also, as some of us pointed out, since the first element of V is unit,
>> some flops can be saved in the unrolled version (for all 4 precisions).
>> 
>> Attached are the proposed patches for the 4 precisions xLARFX.
>> I am attaching the four precisions as I am not sure how the precision
>> generation of LAPACK is done.
>> Note that we are using this routine as one of the main kernels for the 
>> bulge chasing
>> procedure.
>> 
>> Thanks,
>> Hatem
>> 
>> 
>> <dlarfx.f><clarfx.f><zlarfx.f><slarfx.f>_______________________________________________
>> Plasma-devel mailing list
>> Plasma-devel@eecs.utk.edu
>> http://lists.eecs.utk.edu/mailman/listinfo/plasma-devel
>