Axp-Hardware Archive
Re: EV56 and FPU (long)

Subject: Re: EV56 and FPU (long)
From: Phillip Ezolt (ezolt@perf.zko.dec.com)
Date: Wed Dec 15 10:36:03 1999


Jose,
        You really DON'T want to be using the GNU fortran compiler.
Use the compaq fortran compiler at http://www.digital.com/fortran/linux/

Cheers,
--Phil

Compaq: High Performance Server Division/Benchmark Performance Engineering
---------------- Alpha, The Fastest Processor on Earth --------------------
Phillip.Ezolt@compaq.com |C|O|M|P|A|Q| ezolt@perf.zko.dec.com
------------------- See the results at www.spec.org -----------------------

On Wed, 15 Dec 1999, [iso-8859-1] José Javier Zarate wrote:

> Dear all
>
> I am not sure if this are the right lists so if you know better places
> to ask please let me know. Excuse also the cross posting but I am
> desperate.
>
> Not my english language skills neither my programming skills are very
> good so please excuse my possible manifestations of ignorance.
>
> I am using a computer with EV56 microprocessor 633 MHz, API 164UX 2 MB
> cache motherboard, 256 MB RAM and OS RedHat 6.0, kernel 2.2.5-16.
>
>
> Well, the question is that I am trying to make run a pharmacokinetic
> modelling program under Alpha/Linux.
> The program comes as general Fortran code that you have to compile.
>
> Well, the first question is that since I installed
> For setting up the program I should know some values referring to the
> FPU characteristics. I will cite quoted from the installation manual:
>
>
> "REPS Machine precision. The smallest floating point number
> representable
> in the machine such that when added to 1 the result sum is not 1.
> TOL Machine tolerance. The smallest floating point number representable
> in the machine divided by machine precision.
> LARGE Machine infinity. This is the largest floating point number
> representable in the machine.
> EPS Mantissa lenght. This is the number 2**(-m), where m is the number
> of binary digits occurring in the floating point mantissa.
> SREPS Same as REPS but always single precision.
> STOL Same as TOL but always single precision.
> In single precision NONMEM, these six nunmbers are represented as
> integer values in the integer variables IREPS, ITOL, LARGE, IEPS,
> ISREPS, ISTOL.
> In double precision NONMEM, double precision versions of REPS, TOL, and
> LARGE are plced as pairs of integr values in two-dimensional integer
> arrays IREPS, ITOL and LARGE. Single precision versions of EPS, ISREPS
> and ISTOL.
> The integer values in BLKDAT (a subroutine of the program) are made
> equivalent via FORTRAN EQUIVALENCE statements to floating point
> variables of the appropiate precisions."
>
> Double precision values are:
> "
> * IEEE CONSTANTS
> *
> C DATA IREPS,ITOL,LARGE,IEPS/1018167296,0,55574528,0,
> C 1 2146435071,-1,864026624/
> C DATA ISREPS,ISTOL/872415232,201326592/
> *
>
> *
> * INTEL CHIP CONSTANTS
> *
> DATA IREPS,ITOL,LARGE,IEPS/0,1018167296,0,55574528,
> 1 -1,2146435071,864026624/
> DATA ISREPS,ISTOL/872415232,201326592/
> "
>
> Single precision values are:
>
> "
> * IEEE CONSTANTS
> *
> C DATA IREPS,ITOL,LARGE,IEPS/872415232,201326592,
> C 1 2139095039,864026624/
> C DATA ISREPS,ISTOL/872415232,201326592/
> *
> "
>
> I have used Intel and IEEE values but this appears to cause errors
> during
> execution (in test runs I get floating point exceptions) unless I
> compile without optimization. Intel values allow any kind of options
> when compiling.
> So, could any of you know those values for my microprocessor or where to
> find them? I will try to give you more information as soon as I can find
> it.
>
>
> When comparing the time it needs for some problems with the same time
> from a PIII 450 MHz it simply trounces the Alpha in some kind of
> problems (by a factor of two), while resolving some other problems
> result in the Alpha outperforming the PIII by a factor or two. I am
> really lost.
> Are there any benckmarking utilities available that allow me to check if
> the machine is running properly? Or any simple way to check if
> everything is working properly?
> Could any of you have some Fortran program that I could compile and
> check the time it needs to execute?
> Are there any mods I could perform to improve the computer performance?
>
>
> As someone appears to be using the same compilers as I do, would it be
> possible to know what the program is doing (wich subroutines it is using
> during a givwen run an d how much time is it taking). Back to my times
> of BASIC (sorry) and Pascal you could do it and see wich lines of code
> were being executed. Being a program used for clinical purposes I cannot
> modify the source code without previous agreement of the makes but I
> think that I could apply different optimizations to different
> subroutines, as I have seen that applying different optimization levels
> to the whole lot appear to change favourably the performance on some
> problems and degrade it on some others. Any clues would be very welcome.
>
>
> When installing the program I have also the choice of using single or
> double precision installation.
> Quoting again:
> "Some scientific workstations are described as having "64 bit
> architecture". This tipically describes the width of the data bus, not
> the size of the floating point word, wich is 32 bits. Double precison is
> recommended for such machines."
>
> Supposing that the ability of having 64 bit long word allows the
> microprocessor to work with longer than standard single precision
> values so that I could install Single precision version without losing
> quality in the results and improving speed. Or, if someone knows enough
> about the architecture of the processor and how to do it, I could try to
> do what Intel Pentium (and next) do, perform various tasks in parallel.
> Any of those tricks would be very useful. If somebody knows how to
> convince the compiler for having such behaviour I would be very grateful
> if he or sehe could share his knowledge.
>
>
> I have tried to overclock from 633 to 667 but since I did I get
> f77: Internal compiler error: program f771 got fatal signal 11
> when compiling large sets of *.f files.
> After getting back to 633 everything seems to be normal again.
> Any clues about overclocking? I thoght that 5% overclocking wasn't shuch
> a big deal.
>
>
> Finally, floating point exception handling.
> Ther are various ways to do this in different architectures and OSs, I
> need that the program terminates in case of FP exception unless is
> underflow where is considered safe to set the value to zero. Under
> Compaq fortran compiler it appears to be done by the option fpe at
> different levels but I am not sure neither know what is gradual
> underflow (something proposed in the online manual as an alternative to
> setting the number to zero).
>
>
> Thanks all and happy Christmas
>
> --
> JJ Zarate
> Departamento de Farmacia y Tecnologia Farmaceutica
> http://www.unav.es/farmacia/dptos/farmytec/index.htm
>
> --
> To unsubscribe: send e-mail to axp-list-request@redhat.com with
> 'unsubscribe' as the subject. Do not send it to axp-list@redhat.com
>
>



This archive was generated by hypermail version 2a22 on Mon Jan 3 11:15:07 2000 PST
Send any problems or questions about this archive to webmaster@alphalinux.org.