From maintainers-request at octave dot org Wed Dec 15 11:55:09 2004
Subject: Re: started work on new version of LAPACK
From: Piotr Luszczek <luszczek at cs dot utk dot edu>
To: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
Cc: maintainers at octave dot org
Date: Wed, 15 Dec 2004 12:56:54 -0500

John W. Eaton wrote:
> On 14-Dec-2004, Piotr Luszczek <luszczek at cs dot utk dot edu> 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.

Cheers,

Piotr