[Numpy-discussion] Volunteer sought for BLAS/LINPACK restructure

[Paul F. Dubois]

We are seeking a volunteer developer for Numeric who will remove the current
BLAS/LINPACK lite stuff in favor of linking to whatever the native version
is on a particular machine. The current default is that you have to work
harder to get the good ones than our bad ones; we want to reverse that.

We have gotten a lot of complaints about the current situation and while we
are aware of the counter arguments the Council of Nummies has reached a
consensus to do this.

A truly excited volunteer would widen the amount of stuff that the interface
can get to. They would work via the CVS tree; see
http://numpy.sourceforge.net. Please reply to dubois at users.sourceforge.net.

> -----Original Message-----
> From: numpy-discussion-admin at lists.sourceforge.net
> [mailto:numpy-discussion-admin at lists.sourceforge.net]On Behalf Of James
> R. Webb
> Sent: Monday, February 07, 2000 10:04 PM
> To: numpy-discussion at lists.sourceforge.net
> Cc: matrix-sig at python.org
> Subject: [Numpy-discussion] Re: [Matrix-SIG] An Experiment in
> code-cleanup.
>
>
> 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" <beausol at exch.hpl.hp.com>
> To: <numpy-discussion at lists.sourceforge.net>
> Cc: <matrix-sig at python.org>
> 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:beausol at hpl.hp.com
> > Vox: 425-883-6648
> > Fax: 425-883-2535
> > HP Telnet: 957-4951
> > ============================
> >
> > _______________________________________________
> > Matrix-SIG maillist  -  Matrix-SIG at python.org
> > http://www.python.org/mailman/listinfo/matrix-sig
> >
>
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/numpy-discussion