For discussions of all Approximatrix products and related software
You are not logged in. Please login or register.
Approximatrix Forums → User Support → OpenBLAS
Jeff,
First of all, thanks for the version 3.9 (specially for the clipboard functions).
Question, however, concerns BLAS, LAPACK and all that. I understand, that the
libraries, which are distributed with SF, are compiled classics from netlib.
How about optimized OpenBLAS version? Is it possible to use the provided binaries
within SF environment or is better to compile it (with LAPACK) from sources?
In the latter case, this is actually a Package Request :-)
Regards,
Carlos
Carlos,
Simply Fortran actually ships with OpenBLAS on all platforms, not the original Netlib implementations. When you enable BLAS and LAPACK linking in Project Options under the Linker section, it links with an appropriate OpenBLAS library.
However, the OpenBLAS library shipped with Simply Fortran is not necessarily as optimized as it could be. It has been compiled targeting "Generic" CPUs to ensure compatibility with all systems. We were exploring some options that would allow rebuilding of OpenBLAS and possibly the Fortran runtime library on the end-user's system, but we don't currently have a solution.
Jeff,
Thanks for the info. Which version of OpenBLAS is used?
Below some benchmarks, using dgemm and 1000x1000 double precision matrix
openBLAS (as shipped with SF) : 0.625 ms
matmul : 0.078 ms
openBLAS (0.2.19 binary, Haskell) : 0.062 ms
openBLAS (0.2.19 binary, Sandy Bridge) : 0.120 ms
componentwise (native, with -O2) : 0.594 ms
Haskell binaries fails on my laptop with Lapack (dgesv). Sandy Bridge binaries seem to work,
but I will not play a Russian roulette, so I will stay with the "generic" target as shipped.
It is pretty slow, however, so I will check also the "official" binaries of netlib version.
Carlos
Carlos,
Our OpenBLAS version right now is 0.2.19, a bit dated. The 32-bit implementation will be extra slow since it is compiled for generic "686" chips, meaning no vector units are used at all. The 64-bit implementation I believe is safe to assume SSE and SSE2 are present, but I'd have to check. Furthermore, our OpenBLAS is single-threaded, so it is not taking advantage of multiple cores whatsoever. That change would be easier to implement, but we need to change some compiler flags as well, forcing linking with OpenMP libraries (the Fortran runtime library could benefit from this too).
In your examples, you've actually pointed out the problem: one version of the library fails on your laptop. Our maintaining and shipping countless versions of OpenBLAS is untenable. That's why we're considering a system to automate building it for your native CPU once Simply Fortran is installed rather than shipping a binary.
Carlos,
I did want to add that I don't believe our shipped library includes the runtime CPU architecture detection for some reason. I don't recall the original reason for avoiding that feature except, possibly, that the library is enormous size-wise. However, building the library with DYNAMIC_ARCH might be the best choice.
Jeff,
I have found out that the "official netlib" blas/lapack (for win) exists only in a form of dynamic library, which I do not
want to use. Therefore OpenBlas remains as the only choice, furthermore, it incudes the recent versions of
netlib libraries. BTW, netlib LAPACK is (to my surprise) a living project with new, improved and often updated algorithms.
FYI, I succeeded with compiling the recent version of OpenBLAS, using the Linux subsystem on my win10 desktop,
using the instructions from:
https://benniesoft.wordpress.com/2017/0 … -headache/
The obtained library (libopenblas_haswellp-r0.3.9.dev.a) works with SF like a charm, on both laptop and desktop.
If fact, I am curious how this magic is possible at all. Library was compiled under Linux, has .a extension but
works...
Carlos
Carlos,
Netlib's LAPACK and BLAS can be compiled with Simply Fortran directly, but it can be time-consuming to set up. We're actually going to release a new version early next week that should have improved OpenBLAS support on all platforms.
The library having been compiled on WSL and working on native Windows is a bit surprising, but not totally so. The 64-bit calling conventions for x86 chips are pretty much agreed upon by all, in contrast to 32-bit calling conventions, which are varied and complicated. Furthermore, OpenBLAS is strictly a math library with very specific argument definitions, meaning that there is no ambiguity over the size of variables (for example, 64-bit Windows still uses 32-bit integers for int types, which can be confusing).
The .a extension isn't problematic for Simply Fortran, though. If you compile a static library with Simply Fortran, it will be built in that format on Windows.
Approximatrix Forums → User Support → OpenBLAS
Powered by PunBB, supported by Informer Technologies, Inc.