Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#3 error installing on cygwin

Cezary Sliwa

I tried to install 3.8.2 after applying current errata. The result is:

$ ../ATLAS/configure -D c -DPentiumCPS=1825 --prefix=/home/Weronika/atlas --with-netlib-lapack=/home/We
ronika/lapack/lapack_LINUX.a -Ss kern gcc-4 -C ic gcc-4 -C if gfortran-4
gcc -I/cygdrive/c/cygwin//home/Weronika/ATLAS_BUILD/../ATLAS//CONFIG/include -g -w -c /cygdrive/c/cygw
gcc -I/cygdrive/c/cygwin//home/Weronika/ATLAS_BUILD/../ATLAS//CONFIG/include -g -w -o xconfig /cygdriv
e/c/cygwin//home/Weronika/ATLAS_BUILD/../ATLAS//CONFIG/src/config.c atlconf_misc.o
./xconfig -d s /cygdrive/c/cygwin//home/Weronika/ATLAS_BUILD/../ATLAS/ -d b /cygdrive/c/cygwin//home/We
ronika/ATLAS_BUILD -D c -DPentiumCPS=1825 -Ss flapack /home/Weronika/lapack/lapack_LINUX.a -Ss kern gc
c-4 -C ic gcc-4 -C if gfortran-4

OS configured as WinNT (8)

Assembly configured as GAS_x8632 (1)
5 [main] xprobe_sse3 3984 _cygtls::handle_exceptions: Error while dumping state (probably corrupt
ed stack)
5 [main] xprobe_sse2 1636 _cygtls::handle_exceptions: Error while dumping state (probably corrupt
ed stack)

Vector ISA Extension configured as SSE1 (4,48)

Architecture configured as K7 (19)
make[2]: *** No rule to make target `IRunArchInfo_winnt'. Stop.

Bad CPU MHZ value=0, ierr=0, ln2='CPU MHZ=0

Clock rate configured as 0Mhz
make[2]: *** No rule to make target `IRunArchInfo_winnt'. Stop.

Bad NCPU value=0, ierr=0, ln2='NCPU=0

Maximum number of threads configured as 0
make[2]: *** No rule to make target `IRunArchInfo_winnt'. Stop.


    • assigned_to: nobody --> rwhaley
  • OK, all that looks like the normal 3.8 configure. Does the configure die or proceed from there?

    I believe that 3.9.4 configure works a lot smoother under windows, so you might want to try that . . .


  • Cezary Sliwa
    Cezary Sliwa

    The library builds OK. The only non-standard thing is that "make time" asks what is the CPU clock.


  • Cezary Sliwa
    Cezary Sliwa

    I ran a sample program. The performance is inferior, and single precision is not faster at all than double precision. The machine is a 32-bit Athlon (Barton). "make time" looks OK. The compiler is the cygwin-supplied gcc-4.

    gcc version 4.3.2 20080827 (alpha-testing) 1 (GCC)

    Clock rate=1825Mhz
    single precision double precision
    ********************* ********************
    real complex real complex
    Benchmark % Clock % Clock % Clock % Clock
    ========= ========= ========= ========= =========
    kSelMM 202.5 197.4 159.9 145.7
    kGenMM 138.7 147.1 128.0 124.8
    kMM_NT 121.7 109.1 85.2 95.7
    kMM_TN 129.3 113.2 96.6 99.8
    BIG_MM 192.0 192.6 155.7 138.0
    kMV_N 41.1 67.6 21.1 30.9
    kMV_T 39.9 72.1 20.4 33.1
    kGER 24.2 48.8 12.1 24.0

  • So, what you are saying is that make time shows single precision noticably faster, but when you run your own timer, you don't see single precision being any faster than double?

    What problem size are you calling with, and what BLAS routines?

    So, I guess this is an Athlon classic?

  • Cezary Sliwa
    Cezary Sliwa

    The program is a Lahey compiler sample (sampl.f). The single-precision version is the same, but converted to single precision. The output is:

    $ time ./a_atlas.exe
    * *
    * --- dgetrf,dgetrs --- *
    * *
    * If sign of 'OK' is found in 'REMARK' entry the *
    * above subroutines have been certified as correct. *
    * *

    1600 80 OK 0.175E-13

    end test

    real 0m3.390s
    user 0m2.858s
    sys 0m0.062s

    Weronika@kwant ~
    $ time ./as_atlas.exe
    * *
    * --- sgetrf,sgetrs --- *
    * *
    * If sign of 'OK' is found in 'REMARK' entry the *
    * above subroutines have been certified as correct. *
    * *

    1600 80 OK 0.254E-04

    end test

    real 0m3.828s
    user 0m3.202s
    sys 0m0.077s

    The user time for double precision is OK (although I wonder why the real time differs so much, maybe this is the delay due to an antivirus scan...). The single precision timing should be below 2 seconds.


  • I can finally confirm the problem you are reporting, and it is fixed in the developer series after 3.9.7. The problem was that an optimized assembly kernel was being used for double precision, but not for single. I have added architectural defaults for the athlon classic. Here is the result for xdslvtst/xsslvtst:

    === ==== ====== ====== ====== ====== ========= ======== ===========
    ./xdslvtst -n 1600:
    C G 1600 1 1600 1600 3.700 739.15 8.600783e-03

    ./xsslvtst -n 1600:
    C G 1600 1 1600 1600 3.412 801.53 9.841257e-04

    This is on my 600Mhz Athlon classic.

    Give the newest ATLAS developer a try, and I think the problem is solved. Close this request if so, otherwise post details.


    • status: open --> open-fixed
  • Thanks, I will try the development version. Does Athlon XP 2500+ with the Barton core count as an "Athlon classic"?


  • Architecture configured as K7 (20)

    Clock rate configured as 3Mhz

    Maximum number of threads configured as 1
    make[2]: *** No rule to make target `IRunArchInfo_winnt'. Stop.

    Pointer width configured as 32
    Cannot detect CPU throttling.

  • Cezary Sliwa
    Cezary Sliwa

    cd /cygdrive/c/cygwin//home/Weronika/ATLAS_BUILD/tune/sysinfo ; make findNT
    make[4]: Entering directory `/cygdrive/c/cygwin/home/Weronika/ATLAS_BUILD/tune/sysinfo'
    gcc-4 -DL2SIZE=4194304 -I/cygdrive/c/cygwin//home/Weronika/ATLAS_BUILD/include -I/cygdrive/c/cygwin//home/Weronika/ATLAS
    _BUILD/../ATLAS//include -I/cygdrive/c/cygwin//home/Weronika/ATLAS_BUILD/../ATLAS//include/contrib -DAdd_ -DF77_INTEGER=
    int -DStringSunStyle -DATL_OS_WinNT -DATL_ARCH_K7 -DATL_CPUMHZ=1825 -DGCCWIN -DUseClock -DATL_SSE1 -DATL_3DNow -DATL_GAS
    _x8632 -DPentiumCPS=1825 -DATL_FULL_LAPACK -fomit-frame-pointer -mfpmath=387 -O2 -falign-loops=4 -m32 -mpreferred-stack
    -boundary=2 -o xfindNT findNT.o ATL_walltime.o -lm
    /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../libcygwin.a(libcmain.o):(.text+0xab): undefined reference to `_WinMain@16'
    collect2: ld returned 1 exit status
    make[4]: *** [xfindNT] Error 1
    make[4]: Leaving directory `/cygdrive/c/cygwin/home/Weronika/ATLAS_BUILD/tune/sysinfo'
    make[3]: *** [/cygdrive/c/cygwin//home/Weronika/ATLAS_BUILD/include/atlas_pthreads.h] Error 2
    make[3]: Leaving directory `/cygdrive/c/cygwin/home/Weronika/ATLAS_BUILD/src/auxil'
    make[2]: *** [IBuildPtlibs0] Error 2
    make[2]: Leaving directory `/home/Weronika/ATLAS_BUILD/bin'

  • An Athlon XP is essentially the same arch, but it won't use my arch defaults because it will be detected as K7SSE1, rather than K73DNow! :(

    However, with SSE1 detected, you certainly shouldn't get slower float speed, since the peak of SSE1 on that machine should be 4 flops/cycle rather than 2!

    For your later posts, maybe you can post a question as well as random output, so I know what specifically you are asking?

    For your 2nd post on the 15th, I assume the problem you are pointing out is the "Clock rate configured as 3Mhz"? Did this cause probs in the install or not (obviously, it is a bug that needs to be fixed, but I need to know if it a bad bug or just an annoyance)?

    On your post on the 16th, this is a serial machine, right? Did this install succeed or fail?



  • Yes, one problems is that the clock is configured as 3MHz. I fixed this in Make.inc after configure, hence I don't know the impact of this. The second problem is that the number of CPUs is 0 or undefined, yet ATLAS tries to build threaded libraries, which fails. I do not know whether the build of the serial libraries is complete, but make ends with an error.

    You are saying the speed with SSE1 should be OK. Does this apply to 3.8.x also? Even if the -mfpmath=387 compiler switch is in use? The slow speed has been observed with 3.8.x.


  • I forgot to answer you question: yes, the machine is serial (1 CPU).

    Since ATLAS 3.8.x does not include dafaults for K7, what do you think about using 3.6.x?


  • Cezary Sliwa
    Cezary Sliwa

    I observe a similar single precision performance problem with GotoBLAS, i.e. gcc-4/gfortran-4 is slower than gcc 3/g77.

    $ gfortran-4 -v
    Using built-in specs.
    Target: i686-pc-cygwin
    Configured with: /gnu/gcc/package/gcc4-4.3.2-2/src/gcc-4.3.2/configure --srcdir=/gnu/gcc/package/gcc4-4.3.2-2/src/gcc-4.
    3.2 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/sbin --datadir=/usr/share -
    -localstatedir=/var --sysconfdir=/etc --infodir=/usr/share/info --mandir=/usr/share/man --datadir=/usr/share --infodir=/
    usr/share/info --mandir=/usr/share/man -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-
    runtime-libs --with-slibdir=/usr/bin --libexecdir=/usr/lib --enable-static --enable-shared --enable-shared-libgcc --enab
    le-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=ada,c,c++,fortran
    ,java,objc,obj-c++ --disable-symvers --enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp --enable-liba
    da --enable-threads=posix AS=/opt/gcc-tools/bin/as.exe AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe LD=/opt/gcc-tools/bin/ld.
    exe LD_FOR_TARGET=/opt/gcc-tools/bin/ld.exe
    Thread model: posix
    gcc version 4.3.2 20080827 (beta) 2 (GCC)

    $ g77 -v
    Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
    Configured with: /managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/configure --verbose --program-suffix=-3 --prefix=/u
    sr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/s
    hare/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-s
    pecific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-li
    bgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash
    -synchronization --enable-libstdcxx-debug
    Thread model: posix
    gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

  • I just noticed there were new questions here. I'm closing this report: it is too long with too many different topics for me to follow anymore. Will you post any remaining questions again to a new support tracker?


    • labels: 360151 --> Problems during install
    • milestone: 148062 -->
    • status: open-fixed --> closed-fixed