ARSC T3D Users' Newsletter 9, October 21, 1994
List of Differences Between T3D and YMP
The current list of differences between the T3D and the YMP is:
 Data type sizes are not the same (Newsletter #5)
 Uninitialized variables are different (Newsletter #6)
 The effect of the a static compiler switch (Newsletter #7)
 There is no GETENV on the T3D (Newsletter #8)
 Missing routine SMACH on T3D (Newsletter #9)
 Different Arithmetics (Newsletter #9)
Missing Routine SMACH on the T3D
While coding up some exercises for the T3D class, I found an old friend missing. The routine SMACH was added to the BLAS routines when LINPACK came out in 1978. The routine interrogates the machine it's running on and can return three constants that describe the machine's arithmetic: EPS, TINY, HUGE. From the smach.f documentation we have:c assume the computer has c c b = base of arithmetic c t = number of base b digits c l = smallest possible exponent c u = largest possible exponent c c then c c eps = b**(1t) c tiny = 100.0*b**(l+t) c huge = 0.01*b**(ut)Basically we have:
EPS is this definition of the machine epsilon TINY is close to the smallest machine representable number HUGE is close to the largest machine representable number
The Fortran version of the routine is available from netlib (anonymous ftp site: netlib2.cs.utk.edu).But there is a better replacement for SMACH of LINPACK and that is SLAMCH of LAPACK. This routine, SLAMCH, is part of the T3D libraries. LAPACK is meant to be a replacement for the older linear algebra libraries LINPACK and EISPACK. SLAMCH works similar to SMACH by computationally interrogating the machine it's running on and returns a machine arithmetic constant. From the slamch.f documentation we have:
* SLAMCH determines single precision machine parameters. * * Arguments * ========= * * CMACH (input) CHARACTER*1 * Specifies the value to be returned by SLAMCH: * = 'E' or 'e', SLAMCH := eps * = 'S' or 's , SLAMCH := sfmin * = 'B' or 'b', SLAMCH := base * = 'P' or 'p', SLAMCH := eps*base * = 'N' or 'n', SLAMCH := t * = 'R' or 'r', SLAMCH := rnd * = 'M' or 'm', SLAMCH := emin * = 'U' or 'u', SLAMCH := rmin * = 'L' or 'l', SLAMCH := emax * = 'O' or 'o', SLAMCH := rmax * * where * * eps = relative machine precision * sfmin = safe minimum, such that 1/sfmin does not overflow * base = base of the machine * prec = eps*base * t = number of (base) digits in the mantissa * rnd = 1.0 when rounding occurs in addition, 0.0 else * emin = minimum exponent before (gradual) underflow * rmin = underflow threshold  base**(emin1) * emax = largest exponent before overflow * rmax = overflow threshold  (base**emax)*(1eps)So all of the functionality of SMACH and more is available in SLAMCH, which is available in the T3D libraries.
Arithmetic Differences Between YMP and T3D
With the above description of SMACH and SLAMCH, now is a good opportunity to describe some of the differences in the machine arithmetic between the YMP and the T3D. The machine arithmetic for the YMP was determined more than 20 years ago during the design of the CRAY1. Since then, a lot has happened in machine arithmetic, most notably the publication of the IEEE Floating Point Standard 754 in 1981 and its acceptance in 1985. The Dec Alpha chip is implemented according to this new standard.Using the above two functions we can see some of the differences between the arithmetics on each machine:
from SMACH YMP T3D eps = b**(1t) 7.105427357601E15 2.22044604925031308E16 tiny = 100.0*b**(l+t) 1.2902840147914E2450 4.00833672001794556E290 huge = 0.01*b**(ut) 7.7502316430824E+2449 2.49480038691839982E+289 from SLAMCH eps = 7.105427357601E15 1.11022302462515654E16 sfmin= 3.6672077351097E2466 2.22507385850720138E308 base = 2. 2. prec = 1.4210854715202E14 2.22044604925031308E16 t = 48. 53. rnd = 0. 1. emin = 8192 1021 rmin = 0. 2.22507385850720138E308 emax = 8190 1024 rmax = R 1.79769313486231571E+308All of these numbers were gotten from the Fortran versions available from netlib and printed out with a Fortran statement like:
print *, SMACH( 1 )All of the results from the Fortran version agreed with the answers from libsci on both machines. This is just part of the story of the numerical differences between the YMP and the T3D. We will discuss these numerical differences more in future newsletters.
PVM Between T3D and YMP
Last week I requested experience from our users on using the PVM encoding PvmDataRaw between the YMP and T3D. I have tried several test programs and the experience I have on available encodings is:Between T3D and T3D: PvmDataDefault  slowest, loses precision PvmDataRaw  fast PvmDataInplace  fastest, but user needs to synchronize Between T3D and YMP: PvmDataDefault  the only one availableAfter I finish teaching the T3D class, I'll report some timings for each of the above encodings.
ARSC Course Announcement
Title: Applications Programming On The Cray T3D Dates: October 31, November 1,2 Time: 9:00 AM  12:00 M, 1:00  5:00 PM Location: University of Alaska Fairbanks main campus, room TBA Instructor: Mike Ess, Parallel Applications Specialist (ARSC) Course Description: An introduction to parallel programming on CRAY T3D Massively Parallel Processor (MPP). Datasharing, worksharing, and messagepassing programming techniques will be described. The primary goal is to provide practical experience in implementing techniques that enhance overall code performance. These include performance tools for bottleneck determination, debugging and code development tools, and parallel processing principles. This class will have directed lab sessions and users will have an opportunity to have their applications examined with the instructor. Intended Audience: Researchers who will be developing programs to run on the CRAY T3D Massively Parallel Processor (MPP). Prerequisites: Applicants should have a denali userid or be in the process of applying for a userid. Applicants should be familiar with programming in Fortran or C on a UNIX system.
Application Procedure
There is no charge for attendance, but enrollment will be limited to 15. In the event of greater demand, applicants will be selected by ARSC staff based on qualifications, need and order of application.Send email to consult@arsc.edu with the following information:
 course name
 your name
 UA status (e.g., undergrad, grad, Asst. Prof.)
 institution/dept.
 phone
 advisor (if you are a student)
 denali userid
 preferred email address
 describe programming experience
 describe need for this class
Request for References
I received a request for references that describe the T3D hardware that were not from CRI. The only one I know is a good two page description in:Advanced Computer Architecture, Kai Hwang, McGrawHill Inc., 1993If you know of any other good publications about the T3D, email the reference on to me and I'll send it on.
Jokes
Ron Renfrew, the ARSC Analyst in Charge from CRI passed along this quote:Quote of the week, due to David Clark of MIT: "There is an old network saying: Bandwidth problems can be cured with money. Latency problems are harder because the speed of light is fixedyou can't bribe God."
We can expand this list to include both networks and computers:
Solved with money To be solved by God   more bandwidth latency beyond the speed of light more memory infinite precision arithmetic perfectly linear speedups bug free code
Current Editors:
Email Subscriptions:
Ed Kornkven ARSC HPC Specialist ph: 9074508669 Kate Hedstrom ARSC Oceanographic Specialist ph: 9074508678 Arctic Region Supercomputing Center University of Alaska Fairbanks PO Box 756020 Fairbanks AK 997756020

Subscribe to (or unsubscribe from) the email edition of the
ARSC HPC Users' Newsletter.

Back issues of the ASCII email edition of the ARSC T3D/T3E/HPC Users' Newsletter are available by request. Please contact the editors.