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@hpl.hp.com Vox: 425-883-6648 Fax: 425-883-2535 HP Telnet: 957-4951 ============================
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
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
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
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@exch.hpl.hp.com> To: <numpy-discussion@lists.sourceforge.net> Cc: <matrix-sig@python.org> Sent: Tuesday, February 08, 2000 2:31 PM Subject: RE: [Matrix-SIG] An Experiment in code-cleanup. the the header
files that made the recompilation easier than it is now.
Regards,
Ray
============================ Ray Beausoleil Hewlett-Packard Laboratories mailto:beausol@hpl.hp.com Vox: 425-883-6648 Fax: 425-883-2535 HP Telnet: 957-4951 ============================
_______________________________________________ Matrix-SIG maillist - Matrix-SIG@python.org http://www.python.org/mailman/listinfo/matrix-sig
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@users.sourceforge.net.
-----Original Message----- From: numpy-discussion-admin@lists.sourceforge.net [mailto:numpy-discussion-admin@lists.sourceforge.net]On Behalf Of James R. Webb Sent: Monday, February 07, 2000 10:04 PM To: numpy-discussion@lists.sourceforge.net Cc: matrix-sig@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@exch.hpl.hp.com> To: <numpy-discussion@lists.sourceforge.net> Cc: <matrix-sig@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@hpl.hp.com Vox: 425-883-6648 Fax: 425-883-2535 HP Telnet: 957-4951 ============================
_______________________________________________ Matrix-SIG maillist - Matrix-SIG@python.org http://www.python.org/mailman/listinfo/matrix-sig
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/numpy-discussion
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
This should take several volunteers; nobody has access to all machine types!
A truly excited volunteer would widen the amount of stuff that the interface can get to. They would work via the CVS tree; see
That is not necessary; a full BLAS/LAPACK interface has existed for years, written by Doug Heisterkamp. In fact, the lapack_lite module is simply a subset of it. By some strange coincidence I have worked a bit on this just a few days ago. I have added a compilation/installation script and added thread support (such that LAPACK calls don't block other threads). You can pick it up at ftp://dirac.cnrs-orleans.fr/pub/ as a tar archive and as RPMs for (RedHat) Linux. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
(1) The extent of the support for LAPACK. Do we want to stick with LAPACK Lite?
There has been a full LAPACK interface for a long while, of which LAPACK Lite is just the subset that is needed for supporting the high-level routines in the module LinearAlgebra. I seem to have lost the URL to the full version, but it's on my disk, so I can put it onto my FTP server if there is a need.
(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
The low-level interface routines don't take care of this. It's the high-level Python code (module LinearAlgebra) that sets the transposition argument correctly. That looks like a good compromise to me.
(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).
That's already done! Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------------
participants (5)
-
Beausoleil, Raymond -
hinsen＠dirac.cnrs-orleans.fr -
James R. Webb -
Konrad Hinsen -
Paul F. Dubois