[Numpy-discussion] Re: [Matrix-SIG] An Experiment in code-cleanup.

[James R. W. <jr...@go...>]

There is now a linux native BLAS available through links at
http://www.cs.utk.edu/~ghenry/distrib/  courtesy of the ASCI Option Red
Project.

There is also ATLAS (http://www.netlib.org/atlas/).

Either library seems to link into NumPy without a hitch.

----- Original Message -----
From: "Beausoleil, Raymond" <be...@ex...>
To: <num...@li...>
Cc: <mat...@py...>
Sent: Tuesday, February 08, 2000 2:31 PM
Subject: RE: [Matrix-SIG] An Experiment in code-cleanup.


> I've been reading the posts on this topic with considerable interest. For
a
> moment, I want to emphasize the "code-cleanup" angle more literally than
the
> functionality mods suggested so far.
>
> Several months ago, I hacked my personal copy of the NumPy distribution so
> that I could use the Intel Math Kernel Library for Windows. The IMKL is
> (1) freely available from Intel at
> http://developer.intel.com/vtune/perflibst/mkl/index.htm;
> (2) basically BLAS and LAPACK, with an FFT or two thrown in for good
> measure;
> (3) optimized for the different x86 processors (e.g., generic x86, Pentium
> II & III);
> (4) configured to use 1, 2, or 4 processors; and
> (5) configured to use multithreading.
> It is an impressive, fast implementation. I'm sure there are similar
native
> libraries available on other platforms.
>
> Probably due to my inexperience with both Python and NumPy, it took me a
> couple of days to successfully tear out the f2c'd stuff and get the IMKL
> linking correctly. The parts I've used work fine, but there are probably
> other features that I haven't tested yet that still aren't up to snuff. In
> any case, the resulting code wasn't very pretty.
>
> As long as the NumPy code is going to be commented and cleaned up, I'd be
> glad to help make sure that the process of using a native BLAS/LAPACK
> distribution (which was probably compiled using Fortran storage and naming
> conventions) is more straightforward. Among the more tedious issues to
> consider are:
> (1) The extent of the support for LAPACK. Do we want to stick with LAPACK
> Lite?
> (2) The storage format. If we've still got row-ordered matrices under the
> hood, and we want to use native LAPACK libraries that were compiled using
> column-major format, then we'll have to be careful to set all of the flags
> correctly. This isn't going to be a big deal, _unless_ NumPy will support
> more of LAPACK when a native library is available. Then, of course, there
> are the special cases: the IMKL has both a C and a Fortran interface to
the
> BLAS.
> (3) Through the judicious use of header files with compiler-dependent
flags,
> we could accommodate the various naming conventions used when the FORTRAN
> libraries were compiled (e.g., sgetrf_ or SGETRF).
>
> The primary output of this effort would be an expansion of the
"Compilation
> Notes" subsection of Section 15 of the NumPy documentation, and some
header
> files that made the recompilation easier than it is now.
>
> Regards,
>
> Ray
>
> ============================
> Ray Beausoleil
> Hewlett-Packard Laboratories
> mailto:be...@hp...
> Vox: 425-883-6648
> Fax: 425-883-2535
> HP Telnet: 957-4951
> ============================
>
> _______________________________________________
> Matrix-SIG maillist  -  Mat...@py...
> http://www.python.org/mailman/listinfo/matrix-sig
>