lapackers

["Langou, Julien" <Julien.Langou@ucdenver.edu>]

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?

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.

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. 




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