This upgrade will definitely benefit vnl tremendously.  I also like the idea to have the pre-built new v3p_netlib for Windows especially for new users who just begin to compile vxl.

Gehua Yang

On Tue, Sep 20, 2011 at 10:09 AM, Chuck Atkins <> wrote:
Hi all,

As a part of the ITK project,  Kitware and the maintainers of LAPACK/BLAS have been given a short window of opportunity to upgrade the numeric codes used in VXL.  We have about 1 week left on the effort.

Currently VXL, is using older f2c'ed EISPACK, LINPACK, LAPACK, and reference BLAS implementations for many numeric routines.  The plan is to replace the usage of EISPACK and LINPACK with routines provides by LAPACK and to replace the f2c'd versions of BLAS and LAPACK with the ability to consume external implementations.  This will allow for optimized system versions of these libraries to be dropped in to VXL without changing any code.  For example: Apple ships a BLAS/LAPACK with OSX called veclib; Intel provides an optimized BLAS / LAPACK via the MKL library; AMD provides the AMD Core Math Library; ATLAS provides an open source optimized BLAS library, etc. For consuming BLAS and LAPACK libraries from C/C++ we will use the CBLAS interface and newly developed LAPACKE interface.  Both of these provide a standard C API into their respective libraries.  This will also allow us to use these libraries without concern for the row-major / column-major / transpose confusion that often has to take place when working with FORTRAN libraries from C.

One outstanding issue with this new integration is what to do when the user doesn't supply an external BLAS or LAPACK library.  Ideally we would want to remove the f2c'd versions carried locally in v3p since it creates a situation where they are not really maintainable.  Additionally many of the Fortran libraries that are still actively developed and maintained (LAPACK for example) are slowly migrating from Fortran 77 to Fortran 90 / 95 and f2c is really only an option for Fortran  77.  To do this, we have the following 2 options:

1.  User is always required to supply an external library for BLAS and LAPACK.  If not found then the build will fail

2.  If an external version is not found, then the library is built natively as a Fortran library.  This would require that the user has a Fortran compiler installed.  This is not really much of an issue for Unix / Linux users as virtually every compiler suite has a Fortran compiler with it but the situation is a bit different for Windows.  Recent CMake work can really help here though.  The Intel compiler already directly integrates with Visual Studio and some new work in CMake can allow MinGW gfortran to integrate as well.

These are primarily Fortran libraries but if supplied as external libraries, the user will not need a Fortran compiler available.  For Windows, we can pre-build MinGW Fortran libraries that should work with any version of VS.  In general though, it should always be recommended that the user supply an external optimized BLAS library but these are the 2 options (as far as I can tell) if they choose not to.  Similar to the vidl1 -> vidl2 migration, we can create a vnl2 option that is enabled by default where these new features can be available.
Sorry for the short notice, but the funding sort of showed up unexpectedly.  We would like to get this into VXL soon if possible.  It will be put in the ITK version of VNL first.  Of course we will make sure all of the tests pass first, and that it can be easily built on Windows, Linux, and Mac.

As always, we would welcome any feedback.

Chuck Atkins
R&D Engineer, Kitware, Inc.
(518) 371-3971 x603

-- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos

All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
Vxl-maintainers mailing list