From: Chuck A. <chu...@ki...> - 2011-09-20 14:09:50
|
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 I**ntel 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 chu...@ki... -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos |
From: Ian S. <sc...@im...> - 2011-09-20 14:42:53
|
Chuck, Short version: Yes please. Do I understand you right? - You are offering to upgrade a lot of the LINPACK, etc. stuff in v3p_netlib to the modern LAPACK. - In the new version, users will be encouraged to use a platform-provided or other external BLAS/LAPACK library. - If they decline and they have a Fortran compiler, CMake will build a VXL-specific BLAS/LAPACK implementation. - If they decline and have Windows, VXL will have a ready built library binary in the repository. I think the benefits massively outweigh the downside, and can only encourage you. Two suggestions: There is no need to create vnl2, vnl doesn't use BLAS or other bits of netlib. It is vnl_algo2 and v3p_netlib2 that you will need to create. Windows 64bit and 32bit versions of the pre-built new v3p_netlib would be useful. Thanks for doing this work. I'm sure it will be very much appreciated. Ian. On 20/09/2011 15:09, 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 I//ntel 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 <tel:%28518%29%20371-3971%20x603> > chu...@ki... <mailto:chu...@ki...> > > -- "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. > http://p.sf.net/sfu/splunk-d2dcopy1 > > > > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Chuck A. <chu...@ki...> - 2011-09-20 16:12:39
|
> > - You are offering to upgrade a lot of the LINPACK, etc. stuff in > v3p_netlib to the modern LAPACK. > Yes. This work has already been done for ITK's copy of VNL (not pushed upstream in ITK yet though). We were able to remove EISPACK and LINPACK entirely. - In the new version, users will be encouraged to use a platform-provided or > other external BLAS/LAPACK library. > Correct. The reference BLAS library is intended to be used as a reference and for debugging but even the README inside the netlib BLAS library discourages it's use. > - If they decline and they have a Fortran compiler, CMake will build a > VXL-specific BLAS/LAPACK implementation. > I believe we are on the same page but just to clarify: the Fortran libraries that get built by VXL would be the vanilla Fortran code, unmodified, but the library names would be something like libv3p_blas.a and libv3p_lapack.a > - If they decline and have Windows, VXL will have a ready built library > binary in the repository. > Pretty much. Really it's if they decline and don't have a Fortran compiler available (which is likely the case on Windows but not necessarily). I was also planing on the binaries not being checked in to the repository. Either the user could download them manually or we could have the build automatically download the binaries. > Two suggestions: > There is no need to create vnl2, vnl doesn't use BLAS or other bits of > netlib. It is vnl_algo2 and v3p_netlib2 that you will need to create. > Agreed. As vnl is designed / implemented it has no external dependencies and we would only need to do this in vnl_algo. However, I would also like to propose implementing the matrix and vector operators with BLAS routines. It would only be for vnl_matrix and vnl_vector and not for the fixed versions as those tend to be much smaller and likely to benefit more for compile time optimizations than an external optimized library. This has the obvious benefit of accelerating most expressions already implemented with these classes but it also would require that vnl carry an external dependency. I realize though that this is a very different design change that needs to be discussed a bit first > Windows 64bit and 32bit versions of the pre-built new v3p_netlib would be > useful. > Agreed. Thanks for doing this work. I'm sure it will be very much appreciated. > I've wanted a chance to work on this for quite some time and we just happen to finally find a way to fund it. It's definitely not just me though. Julie Langou from the LAPACK team has been invaluable in migrating the codes using EISPACK and LINPACK over to LAPACK while Brad King and Bill Hoffman have been working on the CMake / Fortran / Windows integration. |
From: Gehua Y. <yan...@gm...> - 2011-09-20 14:53:16
|
Chuck, 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. Best, Gehua Yang On Tue, Sep 20, 2011 at 10:09 AM, Chuck Atkins <chu...@ki...>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 I**ntel 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 > chu...@ki... > > -- "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. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > |
From: Joseph M. <mu...@le...> - 2011-09-20 15:15:17
|
Sounds like a good advance to me. It should make it easier to migrate new algorithms into vnl. Joe From: Chuck Atkins [mailto:chu...@ki...] Sent: Tuesday, September 20, 2011 10:09 AM To: Vxl-maintainers Cc: Bill Hoffman; itknumerics Subject: [Vxl-maintainers] VXL Numerics Upgrade 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 <tel:%28518%29%20371-3971%20x603> chu...@ki... -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos |