LAPACK Archives

[Lapack] Vendor libraries, xLA* routines, and SAVE statements.

And Sven Hammarling writes:
 -  > We now need to jump through some hoops to build
 -  > our sgerfsx the condition estimators against MKL.
 - 
 - No.  Just because a vendor makes a silly decision does not mean that we 
 - should.

I over-stated the hoops.  I moved our code over to the
new thread-safe versions, which we needed to do anyways.

Besides, you can't blame them for not talking to their
compiler guys.  They've only had a widely deployed 
solution for problems like this for about two years.

Oh, wait, yes you can.

In many C compilers, the __thread attribute denotes that
a variable is thread-local.  Some library and linker tricks
make it work quite efficiently, and it'd be easy enough to
add to their Fortran compilers[1].  Only time it wouldn't
work is if the same xLACON computation is migrated between
threads.

 - Have you made Intel aware of our new thread safe versions?  Or 
 - would you like me to do that?

I was hoping the guilty party would pipe up, but he may
read only the scalapack list.  Someone with more tact than
I have should volunteer the information.  ;)

BTW, this problem bites ACML, too.  I don't know who to
contact at AMD about it, but someone who hasn't lost the
relevant NERSC seminar announcement does.

Jason

[1] Anyone requesting such a the change will no doubt get
a lesson in how VAX/VMS did it better.

<Prev in Thread] Current Thread [Next in Thread>


For additional information you may use the LAPACK/ScaLAPACK Forum.
Or one of the mailing lists, or