LAPACK and ScaLAPACK Survey Results - ordered by question
LAPACK Usage
Question #5. If you have used both a vendors version of LAPACK and Netlibs, how do the two versions compare? | Responses |
|---|
| vendor lib decreases our runtime by 10%-20% (of calculations taking hours to days). | | vendor's version may only have LU solver, not the full library | | netlib's version is less convenient to use since it does not have Makefiles. | |
Very similar in performance provided you use an optimised BLAS | | Roughly equal, given well optimized BLAS (e.g. Atlas) | | Netlib's version provides the source code, very helpful in porting.
I use vendor's LAPACK functions whenever possible. | |
This depends on the architecture/compiler:
The AMD (ACML) libraries perform very well, though interacting
with the 'fastsse' options on the portland group compiler
can cause rare failures. So most ScaLapack/Lapack libraries
are a mixture on 'pre' and 'locally' compiled.
At NERSC, linking to the 'essl' library , ( for DGEMM) has proved
substantially faster than a user compiled version.
| | I usually try to use the vendor's version first and if it is not available, costs too much, or for some other reason too much work, use Netlib's version next. | | Mostly interchangeable. However, on occasion, the flexibility of configuring through ATLAS has been a key enabler. | | Generally more optimized, although I have not separated out the
BLAS performance (actually use of vendor LAPACK over reference netlib version is often a matter of convenience when using vendor BLAS). | | very similar | | No real differences. | | Similar. Usually performance depends on BLAS, for which the Goto
BLAS performs on par with vendor BLAS. | | vendor version is substantially faster. | | Vendor supplied typically factor 2 faster. | | well. | | Vendor faster but Vendor is incomplete or undefined API (Lapack 1? 2? 3?) | | On Opterons with Portland group compilers under Linux, Netlib version is at least order of magnitude worse. It's useful for testing on a PC though. | | Presume vendor version provides better performance. | | I use MKL on Windows machines and ATLAS on Linux machines. Both perform
better than reference implementations. | | the intel MKL libaries are much easier to use than ATLAS and LAPACK.
despite what others say, I do not find ATLAS to be much faster than MKL
blas (perhaps the difference is not suffient to motivate me to change). | | Vendor's usually does a better job of using cache | | Prefer vendor's version. | | I have run them on different architectures and so have not had the opportunity to do a very direct comparison. | | Never compared. | | Have not compared. Usually I have used the vendor's version assuming they had optimized blas, and maybe lapack. I also assume the vendor is more knwoledgeable (and has more time) to experiment with the different compiler options. Have not actually verified my assumptions, I could be wrong. | | Vendor's version somewhat faster | | Vendor version is more convenient and sometimes optimized. However, my main reason for using a vendor supplied version is convenience in the cases where I don't need portability. | | Sometimes the vender version better performs. | | Similar - Netlib self compiled version is often as good as/better than vendor supplied versions | | Similar | | The overall size of LAPACK library is big for some small platforms. | | Vendor versions tend to be minimally tuned, but better tuned than netlib. | | Vendor code is faster, but not more than 25% | | Sun Performance Library (Solaris 8, 9) had too many bugs. We were on the phone for half and hour or more each time we called in bug reports to Sun and finally decided that their implementation was worthless; we stopped using it and reverted to netlib sources. | | Vendor version is far better (faster). | | Tuning netlib version can be annoying. | | Often e.g. on IBP SP's, the vendor version is better | | no tests performed | | Vendor better on Solaris | | LAPACK is comfortable in some sense because I have been using it (off-and-on) for so many years. However, the differences are all in performance, which is important, but my problems with LAPACK/ScaLAPACK all stem from the interface and that, of course, does not change. | | They are more or less the same, I just don't have to compile / keep manually track of updates with Debian's lapack. | | Vender is much faster | | Vendor versions are *usually* faster, but not always.
| | vendor version is faster | | Vendor's version (MLIB) optimized much better and thus faster | | Vendor version is more prone to errors but is usually faster speedwise.
Having the netlib version available is a good check on the stability
of the vendor version (especially the test suite) | | SGI computer has its own versio of BLAS and LAPACK. It is faster. | | Vendor releases seem only marginally optimized over reasonable
compilation of netlibs code. ATLAS libraries are critical for
any real performance bottle neck. | | Basically the same | | I was never able to get the NEtlib version to pass all it's own tests. I have not submitted the vendor package to the same tests! | | I use ESSL from IBM on p690
At link step, I ask first for ESSL, next for LAPack for completeness.
(ESSL does NOT contain all LAPack subroutines) | | Vendor's version is used for performance and netlib's one for portability. | | vendor's is faster | | Vendor version is much faster | | Comparison is difficult because I only use Netlib LAPACK on architectures for which I don't have access to a vendor version. | | Higher speed for the vendor's version as expected. Same robustness (keeping in mind that I compile the Netlib version with medium optimization flags). | | The vendor version is faster, and I use it because it is free in this case (AMD's ACML). | | I use MKL provided by Intel. Level 2 BLAS routines from MKL are faster than | | I use MKL provided by Intel. Level 2 BLAS routines from MKL are faster than | | Generally the vendor versions are faster showing considerably speed up over the Netlib versions. | | vendor's version of LAPACK much better tuned to their platforms |
|