This release focuses on OS portability, a more thorough set of tests carried out across Operating Systems and distributions, and some more applicable defaults when building the library for a wider audience. The latter is intended to suit maintainers of upcoming Linux distributions who have to think about an unpredictable audience and a wider set of use cases. The second focus point was about dispatching performance-critical functionality independent of the static code path which is selected when building the library. The third focus point was about features supporting developers who want to evaluate LIBXSMM, or incorporate the library into their application.
Here is a list of the main changes along with some more details:
- Validated against Linux and OS X using Travis Continuous Integration. As a side-effect of delivering OS X support (which was requested), the code should also work under FreeBSD when accounting for the specifics (using
gmakerather thanmake, etc.). There is also limited support for Microsoft Windows (no JIT compilation). - A new documentation section about installing LIBXSMM (https://github.com/hfp/libxsmm/#installation) has been written with package maintainers in mind. This is complemented by an removed link-time dependency on LAPACK/BLAS such that the decision about which BLAS library to link with is up to point where the actual application is linked. LIBXSMM works with any (BLAS-)library supplying
?gemmsymbols. - For developers who want to incorporate LIBXSMM, the documentation mentions now how to start with a library (DBG=1) which is emitting messages about internal error/warning conditions discovered at runtime; normally the library is not performing any non-private or visible I/O. In addition, a TRACE facility has been implemented and documented to further support application developers.
- Evaluating and using LIBXSMM has been made very low effort by implementing an LD_PRELOAD mechanism (or DYLD_INSERT_LIBRARIES under OS X). In addition, another but similar mechanism has been implemented to help with an application which is statically linking against LAPACK/BLAS (link-time wrapper). The is an own section about this feature (https://github.com/hfp/libxsmm/#call-wrapper).
- The dispatch mechanism of the internal code registry (which is delivering "dispatching" JIT'ted code) is now dispatched according to CPUID (checks whether the SSE 4.2 based CRC32 instructions are available). In addition to software-based CRC32 Hash keys, an alternative Hash key generator has been implemented to limit the performance penalty in case of CRC32 instructions being not available.
- Fortran applications can now rely on the generated module file and link against 'libxsmmf'. This is complementing the mechanism to simply include LIBXSMM's Fortran interface ('include/libxsmm.f'). In addition, there is limited support for Fortran 77 (
libxsmm_?gemmfunctions only). Some more details can be found at the end of the section about building the library (https://github.com/hfp/libxsmm/#build-instructions). - Finally, the backend code generator has been tweaked for smaller instruction sizes emitted when generating Intel AVX-512 code (Intel Xeon Phi family of processors code-named Knights Landing "KNL").