Changing the way ATLAS does timings

By default ATLAS does all timings with a CPU timer, so that the install can be done on a machine that is experiencing relatively heavy load. However, CPU time has very poor resolution, and so this makes the timings less repeatable and thus tends to produce relatively poorly optimized libraries. Therefore, if you are installing ATLAS on a machine which is not heavily loaded, you will want to improve your install by instructing ATLAS to use one of its higher resolution wall timers.

For x86 machines, ATLAS has access to a cycle accurate wall timer, assuming you are using gcc as your interface compiler (we use gcc's inline assembly to enable this timer - under Linux, Intel's icc also supports this form of inline assembly). ATLAS needs to be able to translate the cycle count returned by this function into seconds, so you must pass your machine's clock rate to ATLAS. In order to do this, you add the following flags to your configure flags:

   -D c -DPentiumCPS=<your Mhz>

So, for my 2.4Ghz Core2Duo, I would pass:

   -D c -DPentiumCPS=2400

If you are not on an x86 machine, or if your kernel compiler is not gcc (or icc if on Linux), then you cannot use the above cycle-accurate wall timer. However, wall time is still much more accurate than CPU time, so you can indicate ATLAS should use its wall timer for the install by passing the flag:

   -D c -DWALL

Note that on Windows XP/NT/2000, this should still get you a cycle-accurate walltime, since it calls some undocumented Windows APIs that purport to do so. For Solaris, the high resolution timer gethrtime will be used. For all other OSes, this will call a standard wall timer such as gettimeofday, which is still usually much more accurate than the CPU timer.

<987>>