ATLAS FAQ

• What is ATLAS?
• Who uses ATLAS?
• What are the academic references for ATLAS?
• Does ATLAS run on my platform (OS/hardware)?
• What software license does ATLAS use (AKA: in what ways and for what purposes am I allowed to use ATLAS)?
• How do I get help/technical support with ATLAS?
• What documentation is available (usage info)?
• What mailing lists, archives, and so on does ATLAS have?
• Can I download a prebuilt binary instead of installing from source?
• Can I get ATLAS in rpm or .deb or some other format?
• What does the version number of ATLAS mean?
• How can I tell what version of ATLAS I have?
• What's the difference between stable and developer ATLAS releases?
• What's the best hardware for running ATLAS/what machine do you recommend I buy for this kind of work?
• Does ATLAS provide a standard C interface to LAPACK?
• Can I use ATLAS with CLAPACK?
• How well optimized are the various routines in ATLAS?
• I need routine/architecture X optimized, can you do it?
• Who wrote/contributed to ATLAS?
• Why does the search limit NB to 80?
• Why don't you speedup/improve ATLAS's search
• What's the deal with the architectural defaults?
• Why are you such a jerk when answering user questions?

INSTALL QUESTIONS:

• Remember that most install questions/problems are discussed in The ATLAS errata file, not here.
• How can I get dynamic (.so) libraries rather than ATLAS's default static libraries (.a)?
• How can I get a complete LAPACK library that uses ATLAS's optimized routines?
• How do I restart a install from scratch?
• How do I restart an interrupted install?
• How can I add F77 interfaces with differing compilers?
• How can I install ATLAS with a non-default F77 compiler?

POST-INSTALL QUESTIONS:

• How can I further optimize the library after install?
• How do I link with the ATLAS libraries?
• How do I get rid of all the object files?
• What LAPACK routines does ATLAS provide?
• What header files should I be aware of?
• How can I run the testers if I have no Fortran77 compiler?
• Is ATLAS thread safe?
• Can I vary the number of threads ATLAS uses dynamically?
• When linking ATLAS's testers, I'm getting a bunch of undefined BLAS symbols (eg. dgemm_, dgemv_, etc).
• What's the deal with the RHS in the row-major factorization/solves?

Who uses ATLAS?

ATLAS is used, or is planned to be used, in the following PSEs:

• MAPLE(v7 and higher)
• MATLAB(v6.0 and higher)
• Mathematica(forthcoming)
• MAPLE(v7 and higher)
• Octave

• Absoft Pro Fortran

• GSL
• HPL
• LAPACK
• MPB
• The R Project
• Scientific Python
• Scilab
• PWSCF
• Scilab

Additionally, ATLAS is included in some way by the following OS distributions:

• Debian Linux
• FreeBSD
• Mac OS 10
• Scyld Beowulf
• SuSE Linux

What are the academic references for ATLAS?

Note that there have been quite a few subsequent papers that discuss ATLAS (with varying degrees of accuracy and detail) written by people not directly involved in ATLAS's production and design. While these papers may be about ATLAS, they are not, obviously, primary sources, and should not be cited as such. If the paper is not authored by Whaley or Petitet, it is not a primary-source ATLAS paper.

@ARTICLE{whaley04,
AUTHOR = "R. Clint Whaley and Antoine Petitet",
TITLE  = "Minimizing development and maintenance costs in supporting
          persistently optimized {BLAS}",
JOURNAL= "Software: Practice and Experience",
volume = "35",
number = "2",
pages  = "101-121",
month  = "February",
YEAR   = "2005",
NOTE           = {\verb+http://www.cs.utsa.edu/~whaley/papers/spercw04.ps+}
}

@ARTICLE{WN147,
AUTHOR         = "R. Clint Whaley and Antoine Petitet and Jack J. Dongarra",
TITLE          = "Automated Empirical Optimization of Software and the
                 {ATLAS} Project",
JOURNAL        = "Parallel Computing",
VOLUME         = "27",
NUMBER         = "1--2",
PAGES          = "3--35",
YEAR           = 2001,
NOTE           = "Also available as University of Tennessee LAPACK Working
                 Note \#147, UT-CS-00-448, 2000
                 ({\tt www.netlib.org/lapack/lawns/lawn147.ps})" }

@inproceedings{atlas_siam,
AUTHOR         = {R. Clint Whaley and Jack Dongarra},
TITLE          = "{Automatically Tuned Linear Algebra Software}",
BOOKTITLE      = "Ninth SIAM Conference on Parallel Processing for
                 Scientific Computing",
NOTE           = "CD-ROM Proceedings",
YEAR           = 1999 }

@inproceedings{atlas_sc98,
AUTHOR    = "R. Clint Whaley and Jack Dongarra",
TITLE     = "Automatically Tuned Linear Algebra Software",
BOOKTITLE = "SuperComputing 1998: High Performance Networking and Computing",
YEAR      = "1998",
NOTE      = "CD-ROM Proceedings. {\bf Winner, best paper in the systems
            category.}\\
            URL: \verb+http://www.cs.utsa.edu/~whaley/papers/atlas_sc98.ps+"
}

@techreport{atlas_wn97,
AUTHOR         = {R. Clint Whaley and Jack Dongarra},
TITLE          = "{Automatically Tuned Linear Algebra Software}",
INSTITUTION    = "University of Tennessee",
YEAR           = "1997",
MONTH          = "December",
NUMBER         = "UT-CS-97-366",
NOTE           = "URL : \verb+http://www.netlib.org/lapack/lawns/lawn131.ps+"
}

@UNPUBLISHED{atlas-hp,
TITLE = "ATLAS homepage",
AUTHOR = "{See homepage for details}",
NOTE   = "http://math-atlas.sourceforge.net/"
}

Does ATLAS run on my platform (OS/hardware)?

What software license does ATLAS use (AKA: in what ways and for what purposes am I allowed to use ATLAS)?

 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *   1. Redistributions of source code must retain the above copyright
 *      notice, this list of conditions and the following disclaimer.
 *   2. Redistributions in binary form must reproduce the above copyright
 *      notice, this list of conditions, and the following disclaimer in the
 *      documentation and/or other materials provided with the distribution.
 *   3. The name of the ATLAS group or the names of its contributers may
 *      not be used to endorse or promote products derived from this
 *      software without specific written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
 * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE ATLAS GROUP OR ITS CONTRIBUTORS
 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 * POSSIBILITY OF SUCH DAMAGE.

How do I get help/technical support with ATLAS?

If you have downloaded the ATLAS source, your ATLAS/doc directory contains some useful documentation, though it is often more dated than the info in the errata and online.

If (and only if) neither of these sources provides the information you need, you can can submit a support request to:

• the ATLAS support tracker.

In addition, please understand that the tone of your support request is important, as described here.

You do not need to create SourceForge account in order to use the tracker (that persistant plea to "please log in" can be ignored), though it makes things easier if you do. In particular, if you don't log in, you won't be able to later attach extra files, etc (you can attach a file in your initial report, but afterwords, it is unsure you are the original poster, so it won't allow it). So, if you think you may need to do this kind of thing relatively often, it may be worth doing.

Note that you should upload the error_[ARCH].tgz file as well. If the error killed the ATLAS install before it succesfully created the error tarfile, create it yourself by issuing the following command from your BLDdir subdirectory:

   make error_report

Note that the [ARCH] of the above directions should be replaced by your architecture string that ATLAS is using (eg., Linux_P4SSE1 or SunOS_SunUS4, etc).

What documentation is available (usage info)?

Here's some pointers to ATLAS documentation:

ATLAS stable errata

Errata file for last stable release. Includes many architecture-specific install hints, as well as documenting and providing fixes for all known errors.

ATLAS installation guide

Guide to configuring, installing, and testing (accuracy and efficiency) ATLAS. Also available in the tarfile at ATLAS/doc/atlas_install.pdf.

ATLAS FAQ

This document. Frequently asked questions about ATLAS.

ANSI/ISO C BLAS API reference

A brief API reference for the ANSI/ISO C interface to the BLAS.

Fortran77 BLAS API reference

A brief API reference for the Fortran77 interface to the BLAS.

Fortran77 and C LAPACK API reference

A brief API reference for the LAPACK routines provided by ATLAS.

Contributer HOWTO [ps] [html]

Paper describing mechanism to speedup ATLAS by contributing kernels.

Developer HOWTO [ps] [html]

Paper with information on how to be an ATLAS developer.

LAPACK homepage

All kinds of LAPACK-related info given at the LAPACK homepage.

BLAS homepage

All kinds of BLAS-related info given at the BLAS homepage.

What mailing lists, archives, and so on does ATLAS have?

ATLAS technical support

The place you go once you are sure you have a technical support issue not covered in the other docs. Anyone can post to this list.

ATLAS feature request list

The place to request additions/extensions to ATLAS. Anyone can post to this list.

ATLAS also has various mail lists and archives. Anyone can sign up or post to these guys. They are:

ATLAS announcement list [browse] [subscribe/unsubscribe/preferences]

Low-volumne list, where significant changes in stable release are announced. Mainly used to announce new stable releases, perhaps occasional updates about very important features appearing in developers' release. Traffic should be O(10) messages a year.

ATLAS error list [browse] [subscribe/unsubscribe/preferences]

Low traffic list for errors found in the ATLAS stable release. Errors in config or install portions are generally not reported, but those involving getting incorrect results or substantial performance penalties are. The idea is that the people monitoring this list are using a successfully installed ATLAS library, and want to be informed if errors are discovered.

ATLAS developer list [browse] [subscribe/unsubscribe/preferences]

Relatively high volume list for ATLAS developer communication.

ATLAS Performance/results list [browse] [subscribe/unsubscribe/preferences]

Mailing list for reporting performance results from ATLAS.

ATLAS CVS commits list [browse] [subscribe/unsubscribe/preferences]

High volume traffic list, with a message for each CVS commit.

Can I download a prebuilt binary instead of installing from source?

What does the version number of ATLAS mean?

Major number

Major release numbers are changed only when fairly large, sweeping changes are made. Changes in the API are the most likely to cause a major release number to incremement. For example, when ATLAS went from supporting only matrix multiply to all the Level 3 BLAS, the major number changed; the same happened when ATLAS went from supporting only Level 3 BLAS to all BLAS.

Minor number

Minor release numbers are changed at each official release. Even numbers represent stable releases, while odd minor numbers are reserved for developer releases. Click here for an explanation of developer and stable releases.

Update number

Update numbers are essentially patches on a particular release. For instance, stable ATLAS releases only occur roughly once per year. As errors are discovered, they are errataed, so that a user can apply the fixes by hand. When enough errata are built up that it becomes impractical to apply the important ones by hand, we will issue an update. So, stable updates are typically bug fixes, or important system workarounds, while developer releases often involve new code. A typical number of updates to a stable release might be something like 4. By their very nature, each update to the developer release usually contains new code, and they can happen relatively rapidly. A developer release may have any number of updates.

So, 3.2.1 would be a stable release, with one group of fixes already applied. 3.3.12 would be the 12th update (13th release) of the associated developer release.

How can I tell what version of ATLAS I have?

main()
/*
 * Compile, link and run with something like:
 *    gcc -o xprint_buildinfo -L[ATLAS lib dir] -latlas ; ./xprint_buildinfo
 * if link fails, you are using ATLAS version older than 3.3.6.
 */
{
   void ATL_buildinfo(void);
   ATL_buildinfo();
   exit(0);
}

If you are using an ATLAS version prior to 3.3.6, there is no easy way to find the version information without looking at the source. If you have the source tree around, the easiest fix is to examine pretty much any source file (eg. ATLAS/src/auxil/ATL_lcm.c); the major and minor version number will be given in the copyright notice at the top. To find out the update number, you'd have to consult the actual routines updated by the particular update, as given in the ATLAS errata file.

If you still have the directory where you built ATLAS around, you can find this version information w/o writing the above routine by:

   cd BLDdir/bin
   make xprint_buildinfo
   ./xprint_buildinfo

Developer releases, on the other hand, are meant to be used, as the name suggests, by ATLAS developers, contributers, and people happy to live on the bleeding edge. Developer releases are meant to allow access to the newest ATLAS sources, and may represent a simple snapshot of the internal developer tree. As such, they are essentially untested, and may not build, much less run, correctly. So, while they may possess features not available in the current ATLAS release, only the most experienced of users should consider utilizing them.

Developer releases are available from the developer site, while stable releases are available from the ATLAS main page. Stable and developer releases are also distinguished by their version numbers, as explained here.

What LAPACK routines does ATLAS provide?

• [S,D,C,Z]GESV
• [S,D,C,Z]GETRF
• [S,D,C,Z]GETRS
• [S,D,C,Z]GETRI
• [S,D,C,Z]TRTRI
• [S,D,C,Z]POSV
• [S,D,C,Z]POTRF
• [S,D,C,Z]POTRS
• [S,D,C,Z]POTRI
• [S,D,C,Z]LAUUM

Since LAPACK has no official C API, ATLAS provides its own in ATLAS/interfaces/lapack/C/src/.

What header files does ATLAS provide?

How can I get dynamic (.so) libraries rather than ATLAS's default static libraries (.a)?

Can I use ATLAS with CLAPACK?

How well optimized are the various routines in ATLAS?

• Level 3 BLAS are very general in their optimizations, and will be competitive on almost all cache-based architectures possessing a decent ANSI/ISO C compiler.
• The provided LAPACK routines utilize a recursive algorithm that should yield reliably better results than the more common staticly-blocked algorithms.
• The Level 1 and 2 BLAS are less general, and may not perform as well on significantly different architectures (eg., IA64).

I need routine/architecture X optimized, can you do it?

A quicker way to get action is to do it yourself. ATLAS is open source, and The developer homepage explains how you can use ATLAS to optimize various operations.

How is ATLAS funded?

I originally started ATLAS development when I worked at the Innovative Computer Laboratory at the University of Tennessee. I got enough of it working to convince Jack (Dongarra, of LAPACK and BLAS fame) to give the development go-ahead on my own time. After that, ATLAS was written into a variety of grants, but was never funded (to my knowledge) solely on its own grant at ICL. I believe some of it's later development took place under the NSF grant "Linear Algebra Algorithms and Tools for Emerging Computing Environments and User Communities", Grant Number ACI-9813362.

Both Antoine and myself (the two full-time ATLAS researchers and developers) left ICL in 2001. After this date, ATLAS work was pretty much entirely unsupported, which slowed development in a massive way. However, in 2003, Advanced Micro Devices funded a year of my graduate studies in return for some Opteron tuning. This allowed me to spend quite a bit more time on ATLAS than previously, and resulted in the release of ATLAS 3.6.0 in that year.

After this, I found very little time to work on ATLAS due to faculty duties until 2006 when I got funding for both research and maintainence, thanks to both NSF and DoD. Details can be found here. ATLAS development has therefore picked up again, and ATLAS 3.8.0 was released in October of 2007.

At present, the main support for ATLAS comes from my CAREER award. The government contract was not transfered to LSU, but Tony Castaldo is supported on it until mid-2014.

Who provides infrastructure support?

As far as machine access for tuning:

• Apple has provided local G4, G5, CoreDuo, and Core2Duo access for ATLAS development.
• Kate Minola at the University of Maryland, College Park, provided access to a wide array of machines for the most ATLAS 3.8.0, including providing my sole access to solaris/x86 and AIX/POWER4.
• William Stein gave me access to his UltraSPARC III platform.
• I have access to a wide variety of architectures through my old colleagues at ICL.
• Advanced Micro Devices provided local Opteron access for ATLAS3.6 development.
• I've used machines through Sourceforge's compilefarm.

Who wrote/contributed to ATLAS?

In particular, ATLAS has been designed to allow for outside contribution such that a user can provide only a very small kernel, and thus speed up large portions of the library. Many people have contributed in this manner, and this has resulted in extremely large performance improvements for ATLAS on certain architectures. These contributers (in alphabetic order), and a rough sketch of what they have done, are:

Doug Aberdeen

His work on emmerald (an SSE-enabled SGEMM), and help on atlas developer mailing list, was the starting point for a lot of people working on SSE-enabled kernels.

Matthew Brett

Initial work and help with getting ATLAS to build dynamic libraries.

Nicholas Coult

Initial version of AltiVec-enabled SGEMM.

Tony Castaldo

Discovered importance of issuing instructions in sets of 4 for PowerPC970, which allowed us to increase dgemm kernel performance from 75 to 82.5% of peak.

Markus Dittrich

Found shell technique allowing configure to pass multiple words as a single flag.

Dean Gaudet

Initial work on using CPUID in configure, Efficeon tuning information, and many informative atlas-devel discussions on related matters.

Kazushige Goto

His ev5/ev6 GEMM was used directly by ATLAS 3.6 and older if the installer answers "yes" to its use during the configuration procedure on an alpha processor. This results in a significant speedup over ATLAS's own GEMM codes, and is the fastest ev5/ev6 implementation we are aware of. Explicit support for alphas was dropped in ATLAS 3.8.0.

Jeff Horner

Initial versions of Level 3 BLAS tester/timer, C interface to the Level 3 BLAS, and non-generated complex matmul code.

Camm Maguire

SSE and SSE2 kernels enabling large speedups for Intel architectures. Also maintains ATLAS (along with other packages) for debian distribution.

Tim Mattox and Hank Deitz

Provided an extremely efficient SGEMM 3DNow! kernel for Athlon.

Viet Nguyen and Peter Strazdins

UltraSparc-optimized [D,Z]GEMM kernels.

Julian Ruhe

Incredibly efficient Athlon matmul kernel.

Peter Soendergaard

SSE and 3DNow! kernel work, enabling large speedups on Intel and AMD archs. Also, translation of Julian's Athlon kernels from NASM to gnu assembler, and extention to all precisions.

Carl Staelin

Initial work on parallelizing ATLAS make.

For ATLAS 3.8.0, I did all testing myself, though several developers provided me with machine access.

Is ATLAS thread safe?

Can I vary the number of threads ATLAS uses dynamically?

What's the deal with the RHS in the row-major factorization/solves?

Why don't you speedup/improve ATLAS's search

1. Why don't you improve the type of search?
2. Why don't you improve the speed of the search?
3. Why don't you improve the accuracy of the search?
4. Why don't you search NB > 80?

Why don't you improve the type of ATLAS's search?

Why don't you improve the speed of ATLAS's search?

There are many places in the search where I could prune things back and have no effect on performance on any known architecture, but since the speed is adequate, additional search options are left on in case an unexpected architectural change is found. I could also utilize more sophisticated sampling techniques, but these would then need to be validated to work on the vast array of machines (the present search having been tested for over seven years, and on innumerable architectures). All this is to say that speeding up the search is not a bad thing, it just is not that helpful to the core usage of ATLAS, and so it is not worth the cost/risk of change at this time. If additional tuning capabilities are added, so that the search time becomes more critical, then of course the search will be updated.

Why don't you improve the accuracy of ATLAS's search?

For most systems, you can at least tell ATLAS's configure to use the cycle-accurate wall timers, which will make all timings much more accurate if you are on an unloaded machine.

Ultimately, a search with some real statistics should be built, which would determine if two timings are statistically different or not, and also use some statistics to see how many probes are required to get reliable results. This is the area that I think I a most likely to improve the search in, if I ever have time.

What's the deal with the architectural defaults?

1. Is using the architectural defaults important, rather than doing my own search?
2. When should I not use architectural defaults?
3. If I don't use architectural defaults, how can I get better performance?

Empirical searches, when ran on real machines experiencing unrelated load, are almost never strictly repeatable, even in the best of cases. The default ATLAS search is far from the best case: the sampling and timing mechanisms are crude, made to work on the lowest-common denominator setups, up to and included embedded systems. So, when run in this mode, the search is designed to give you a library that isn't bad, but is often far from the best.

To get better results (which are then saved as architectural defaults), I usually run the search multiple times, and if necessary, intervene by hand to probe promising transformations. Thus, the architectural defaults can be thought of as a save of several installs + some user intervention. Also, the architecural defaults are synergistic with the default compiler flags, so you want to leave both alone for best results.

When should I not use architectural defaults?

The first thing to check is that your library runs about the same as those that you would get using the architectural defaults. You can determine this by make time, as described here.

If you choose not to use the recommended compiler and architectural defaults, be sure to follow these directions. If you suspect your performance is suboptimal, open up a support request and ask.

If I don't use architectural defaults, how can I get better performance?

Play with the different compiler and flags to find things that better match both the defaults, and your output flags. Be sure to do all the normal post-install tuning, including tuning CacheEdge. Finally, if your install is indeed faster than the arch defaults, report it.

Why does the search limit NB to 80?

There are three main factors why even true asymptotic speedup from large blocking factors are a bad idea:

1. Overall GEMM performance is usually decreased, because more time is spent in cleanup (called when one or more dimensions are not a multiple of NB). For many GEMM calls, very large NBs result in calling nothing but the relatively poorly optimized cleanup.
2. Application performance, which usually calls GEMM with varying sizes, most of which are of modest dimension, spend even greater proportion of their time in cleanup code, and thus experience much greater slowdown than individual GEMM calls.
3. Many applications have unblocked code, and in some cases, the blocking factor may not necessarily match GEMMs. In this case, a large NB can guarantee that all GEMM calls go straight to cleanup. Even when this doesn't happen, as NB rises, the number of calls to GEMM goes down, and since large NB gemm requires larger matrices to reach its asymptotic peak, even recursive factorizations (the best case for large-NB GEMM) need to get extremely high efficiency for the large GEMM cases to overcome the slowdown on the small cases. For fixed-NB cases as in the LAPACK factorizations, large NB are almost always a loss. This is the main reason that ATLAS is reluctant to use large NB.

Note that points (2) & (3) are very important: GEMM is one of the most studied performance kernels in the world not for its own sake, but due to the wide variety of applications whose performance can be improved by speeding it up. Thus, speeding up GEMM at the expense of application performance is something that only someone interested in benchmarking GEMM (as opposed to building a usuable library) would want to do.

Therefore, the ATLAS search limits NB to 80. We occasionally relax this limit (manually, never blindly in the search) when it is absolutely necessary. For instance, on SPARCs, large NB have proven necessary for decent performance, and on the Pentium 4 (not P4E), the floating point unit does not make use of the L1 cache, and so we block for the L2. However, in these cases we first verified that the win is true and substantial, and we then hand-tuned the cleanup to ameloriate the effects of large NB as best we could. Even so, these systems can display very bad performance due to point (3) above, and we actually do not use the best NB for GEMM performance even so, as we increase it only large enough to get adequate asymptotic performance. Without examining this tradeoffs, you should never increase NB, unless you are tuning for a large GEMM benchmark.

Does ATLAS provide a standard C interface to LAPACK?

I believe most of the vendors provide some C interface to LAPACK; I think most of them just use the same name (eg, F77's DGESV becomes dgesv), and the scalars become pass-by-value. ATLAS provides a C interface to the LAPACK routines natively provided by ATLAS, which is based on the standardized C interface to the BLAS. These routines are prefixed with clapack_, and their prototypes can be found in ATLAS/include/clapack.h. ATLAS natively provides only a handful of LAPACK routines, so if you want to call something that is not provided here, your best bet is to call the Fortran77 interface. The good news about this is that being a standard interface, all lapack libraries should support it in the same way.

Why are you such a jerk when answering user questions?
AKA: how can I help you feel good about providing me with support?

Even if you are not going to read through all the docs, if you are submitting a support request, at least take the time to read the FAQ entry on how to submit a support request. Almost half my users send in a message that translates to I haven't read the docs, and they post it to the "bugs" list, which is reserved for developer-verified bugs.

Let me show the absolute best kind of support request I get:

Subject: Problems with 3.5.8
Hi,

I've been using it in my chemistry research in order to do XXX for a couple
of years now, and ATLAS is a great piece of software!  However, I'm
now having a problem getting the newest release to work.

As I said, I get maybe one or two messages of this type a year. I get quite a few absolutely neutral messages, which are OK as well. They don't imply that the problem is necessarily in my software or my brain, but rather just report that a problem has been encountered. They go more like:

Subject : matvec problems
Whenever I call matvec with N=200, my install seems to get worse performance
than the reference BLAS.  Any idea why?  I include my timer below.

Thanks,
My Name

Subject : error in matvec
Your matrix-vector product has an error.  For N=200, it is slower than the
reference BLAS!  Please fix this.

Another thing that users do that drives me crazy is to insist that something done in a way they don't like is a bug, rather than a disagreement between the developer and a user on how things should be done. I'm not sure what the motivation here is, but users will often argue that anything that didn't work the way they expected was a "bug", even if it was documented to work another way. I, like many good software developments, am a bit of pedant, and insisting on calling your preference a bug in my software often irritates me so much that I cannot objectively determine if your preference is preferable (assuming its something I have the freedom to change, which I often don't). Therefore, if you think there are improvements to be made, suggest them as improvements, or things that would be convenient for for you, rather than terming them bugs.

Keep in mind that the author of a package probably consideres himself more knowledgable than the majority of his users on issues closely related to his project, and so it may grate upon him to have users tell him that he has done things the wrong way, or doesn't understand how "modern" libraries work, etc. So, I would avoid phrasings like can you fix the insane way config works? or how about doing this in the correct way (yes, I really get messages like this).

Another important thing is to understand the context the author is working in. If you see a piece of code that is truly horribly written, or works in a particularly awkward way, you may feel justified in arguing that the author has simply done it all wrong, should call it a bug, and fix it! However, the author is not responsible only for the couple hundred lines of code you are examining. In my case, I am responsible for roughly half a million lines of code, as well as continuing development. Therefore, I may actually agree that a particular way of doing things is sub-optimal, but if it is well-tested to work on the enormous number of platforms ATLAS runs under, I will often decide to leave it alone, in order to concentrate on more important concerns. Even in the case where the author agrees with you that the code is a complete POS, a little tact on your part will go a long way. Understanding that the author is not always free to rewrite the section of code of greatest interest to you will go even further.

Well, I am not confident that users will read this, but I am confident that I will use its URL in replying to a lot of future user requests, so I think this time away from development is well spent!

Cheers,
Clint