math-atlas-errors Mailing List for Automatically Tuned Linear Algebra Soft.

Guys,
It became obvious that I had too much work still to do on the developer
series to stabilize it for this summer, so I have issued 3.10.2 that
fixes several bugs in the old stable.
There are quite a few bug fixes, but probably the most important are:
 http://math-atlas.sourceforge.net/errata3.10.1.html#syrknan
 http://math-atlas.sourceforge.net/errata3.10.1.html#cqtau
 http://math-atlas.sourceforge.net/errata3.10.1.html#sztyp
These bugs may effect even a successfully-installed 3.10.1, so you may
want to scope them to see if you want to install 3.10.2.
3.10.2 doesn't have any performance wins that I know of over 3.10.1.
Since the developer series has changed the GEMM kernel usage,
backporting kernel support doesn't really work, so if you are using
modern machines (vectorization of AVX or later for x86), the developer
series can more than double performance over the stable. Due to the
ongoing threading rewrite, the developer can also be much more efficient
when your number of cores exceed 4 or so.
So, for best performance, you may want to see if the developer series
works on your platform. If it does, you can run all the provided tests
that I do during stabilization, which should make it almost as reliable
as the stable release for a given platform (though this takes some
knowledge; I can provide some help if needed).
Regards,
Clint
ATLAS 3.10.2 released 07/10/14, highlights of changes from 3.10.1
 * Fixed all errataed bugs:
 + Failure to init workspace can cause NaNs in SYRK
 + Complex row-major Q-type factorizations produce bad TAU
 + Failure to cast causes integer overflow on 64-byt platforms
 + Missing IBM S390 assembly file
 * Fixed Make.bin to have threaded latime built to do parallel cache
flushing
 * Extended extract string lengths as patched by SAGE folks
 * Backported fixes & some arch support to configure framework, including
 host of Itanium and UST1 stuff provided by SAGE folks
 NOTE: 3.10.2 is terribly out of date, and was released only because the
 threading rewrite it taking too long. If possible, you should use a
 developer release after testing that it works for your particular
 platform. In particular, developer releases are *much* faster
for any
 x86 that uses AVX or later SIMD ISA, or any machine with ncores >= 8.
 The developer release also supports ARM architectures better (though
 performance is not hugely better if you can get stable installed).