[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: started work on new version of LAPACK

From: Piotr Luszczek
Subject: Re: started work on new version of LAPACK
Date: Wed, 15 Dec 2004 12:56:54 -0500
User-agent: Mozilla Thunderbird 0.9 (X11/20041103)

John W. Eaton wrote:
On 14-Dec-2004, Piotr Luszczek <address@hidden> wrote:

Hi Piotr,

Thanks for considering the Octave community in your plans.

Thank you for using Lapack :)

In this email, I'm going to answer some of your points.
The entire email will be distributed among our developers.

| - support for threading (OpenMP, pthreads, etc.)

Can you give some more details about what this would provide?

The chip industry seems to be moving away from increased frequencies
to multicore designs. This trend combined with all various SMPs
in existence make us believe that Lapack should know about threads.

We might not make the Lapack multi-threaded and delegate this
responsibility to BLAS but still Lapack should be thread-safe
at the very least. It is not right now. xLAMCH routines come
to mind - they have a SAVE statment (static storage) which will
be a problem. We don't want to make mistakes like this anymore.

Of course there is possibility to build some threading into
Lapack itself and let it call single-threaded BLAS. There are
pros and cons for both threading approaches.

Finally, there is the issue of system calls. I/O and memory allocation
will mostly likely result in a system call and that sometimes has
problems with threads. We want to be careful about this.

| - 64-bit addressing

This would be useful.  There is some work underway to allow Octave to
handle >2GB arrays.  I have been wondering what the correct solution
is for the problem of calling LAPACK routines when we have 64-bit
ints.  I think the current patches assume that any Fortran code has
been compiled such that all INTEGER data is 8 bytes.

We're thinking of some sort of wrapping around existing 32-bit BLAS
just to get a clean 64-bit interface without any assumptions about
compiler flags.

| - IEEE 794 (floating-point) support

Yes, I think it would be best if LAPACK (and BLAS) supported
operations on Inf and NaN "correctly" by default.

Definition of "correct" depends on whom you ask :)
I don't know what is going to be decided.

Also, I think that people will expect performance like ATLAS.  OTOH,
maybe you are only thinking about the interface and a reference
implementation and would still leave optimization up to other
projects?  In that case, then I would hope to see ATLAS adapted to use
the new algorithms and interface defined by the new LAPACK.

We're thinking of installation-time tuning of ILAENV (a query routine
that is used throughout Lapack to get performance parameters).

Atlas will not be our responsibility. We consider it for now a BLAS
implementation (even though it has some Lapack routines in it).
But of course we will be collaborating with Clint (Atlas' main developer).

Finally, here are some other minor things that I can think of
  * A public mailing list for bug reports.

We're in the process of setting up Bugzilla. We will put old bugs
in there and it will be open to submit new bugs.

The Lapack user list is:
lapack at cs dot utk dot edu

We get questions and bug reports there all the time.

Another communication channel would be a forum.

Thank you for your input.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]