LAPACK and ScaLAPACK Survey Results - ordered by question
LAPACK Usage
Question #14. If you have installed LAPACK yourself, how could the installation process be improved? | Responses |
|---|
| Haaave the default make target *not* run the test phase. | | would be nice if the testing and verification process is quicker | | use a simple configure script | | It could not be improved | | This is a minor issue: complete the LAPACK implementation in ATLAS so that optimized BLAS and LAPACK can be installed in one package. | | The testing process is too slow. It's hard to believe the functionality oculdn't be tested with quicker-running problems. Perhaps have the option of the long test if you want it. A typical scenario is that I get onto some new machine and find I have to install LAPACK, then I can kiss productive time goodbye waiting for the tests to run. | | More automatic configuration, and some basic tuning. | | Place in autoconfig construct as a package in itself
Place in autoconfig construct with scalapack, lapack, blas
./configure --with[out]-(scalapack,lapack,blas) --with-blas=ibm_essl | | If you can have binary version for all the systems, it will be great. | | not much, current method is fairly straightforward | | I have not done this recently.
Several years ago, I had difficutly using the compiler that came with my linux distribution (I think either atlas or lapack required an older version).
| | Does it use GNU autoconf and automake? | | rpm, if possible | | it's simple enough | | LAPACK always seem to compile fine, but
testing routines often fail for non-obvious reasons. | | 1. I always compile and create the libraries manually. Provide a script or makefile that does just that. The official installation process is confusing and gets stuck.
2. provide standard ./configure make make install but make sure it actually works on (nearly) everything | | The LAPACK installation process itself isn't bad once you've done it a few times. What would be really nice is if it followed the GNU style "./configure ; make ; make check ; make install" sequence. I install tons of software for the team I support and reallly appreciate those tools that use familiar and consistent configure scripts & build env variables (CFLAGS, etc). Another pain--and this isn't LAPACK's fault--is building an ATLAS-enhanced LAPACK. Sure, it is easy once you've done it a few times but the process is really non-standard. | | It is ok. | | Precompiled downloads work for me | | LAPACK currently has no configuration support. Manually editing makefiles is fine for most wonks like us, but it's not very "professional" for an NSF project funded at LAPACK's level. Autoconf configure scripts would be very slick and help provide built-in support for building LAPACK on various frequently-used architectures. | | dlamch tuning could be simplified? | | I have not seeen any problem with the installation process | | configure script rather than multiple makefiles + user choice | | It should build shared libraries, not just static. | | Unless the architecture is new, there seem to be few problems. Even with ScaLAPACK, I have encountered few problems in this respect. It was very well done. | | Many recent compilers seem too clever for automatic detection of parameters like machine epsilon to work. It would be useful to have a replacement that uses Fortran 90 intrinsics instead. | | it always worked fine for me | | Make the default install double & double complex only. Improve the test
suite (it fails eg on some compilers when attemmpting to discern the
machine accuracy/tolerances). | | Export .exp files for use with MSVC++ on Windows would be slightly nice to have, though this is a minor issue.
| | No problems with installation... | | Been a long time since I did this - Think it's OK as is. | | ok as is | | autoconfig!! Manually tweaking makefile options and manually installing the library is a pain. This would also allow for more reasonable shared library support.
Also, go ahead a make a LAPACK 3.1 or 3.0.1 (or whatever you'd call it) release. Downloading the lapack-3.0 sources and then manually copying all of the patch files on top of the originals is a pain. | | configure / make | | Installation is not a problem. | | see Scalapack comments below. | | I feel the installation process was extremely simple. I can't suggest any improvements. | | Maybe an ATLAS-like procedure that reduced the optimization levels only on routines that tend to fail on a given arch/compiler combination and optimized the rest. | | I know just enough about the install process to get into trouble. I originally tried to install just the single and double precision routines, but the install would not complete. It was easier to just default the install to create the full library with all four precisions/kinds | | One could consider to provide makefiles for some popular platforms and compilers like Intel compilers. | | One could consider to provide makefiles for some popular platforms and compilers like Intel compilers. |
|