ARSC T3E Users' Newsletter 126, September 26, 1997

Yukon Upgrade

The recent upgrade to the ARSC T3E, or yukon, as described in the previous edition of the newsletter has now been completed. The majority of the changes made over the past weekend are to the hardware and users should see the impact of these without needing to make any changes to codes, scripts etc. However below are some hints as to how users can take best advantage of the improvements made to the system.

Physical Changes

Additional Memory
The memory on each node has been doubled to 256Mbytes. This will allow users to either use fewer processors to perform the same work, or to increase the size and complexity of models already running on the system. The best use of ARSC resources will occur if all users employ the number of processors which provide enough, and just enough memory for the work they wish to perform. (As a reminder, the T3E allows users to run on non-power of 2 processor sets, so users should consider carefully the exact requirements of their problem and choose a suitable number of processors.)

Streams
The current processors are now fully streams safe, code modifications are no longer necessary. Users should see an improvement in performance due to this. Full details of the nature of streams can be found in:

"The Benchmarker's Guide to Single-processor Optimization for CRAY T3E Systems"
By: Ed Anderson, Jeff Brooks, and Tom Hewitt; Benchmarking Group, Cray Research.

Which is available in postscript via anonymous ftp to: ftp.arsc.edu. It is in the directory: pub/mpp/docs, and is named: bmguide.ps.Z. We also refer you to the man page, man intro_streams, available on yukon.

Some users are reporting a near doubling of performance with particular codes. However this improvement might not be obtained by all users codes. Users might like to compare performance of programs with and without streams. Streams are enabled by default but users can run without streams by setting the following environment variable before running a parallel executable.

e.g.
        yukon% mpprun -n 8 ./a.out > output_streams_on
        yukon% setenv SCACHE_D_STREAMS 0
        yukon% mpprun -n 8 ./a.out > output_streams_off
        yukon% unsetenv SCACHE_D_STREAMS

The final unsetenv returns the streams status to the system default, i.e. enabled.

Clock Speeds
The clock speed of each processor has been increased from 300MHz to 450MHz. This provides a theoretical maximum peak performance of 900Mflops for the new processors. Benchmarks show a speedup of between 1.2 and 1.3 when compared to the 300MHz processors for typical scientific and engineering codes.

Additional Processors
Eight processors have been added to the system bringing the physical total to 104 processors. Six of the new processors have been added to the application processors for users applications, the remaining two are command processors which support user jobs and logins etc. At present the additional processors are primarily for interactive use. This is to provide resources for those performing interactive work during the migration of codes from the T3D to the T3E. However, in the future, the total number of processors available to NQS will be increased and a new queue structure introduced.

Queue Structure

In order to reflect the changes in system configuration and performance, we will be making a number of changes to the queue structure during test time in the coming weeks. These are still being discussed, so please see news on yukon for more details. These changes will be aimed at increasing the throughput of the system and likely changes are to reduce the maximum time of any job and to change the processor number limits to reflect the ability to run on non-powers of 2. Feedback is welcome on queue structures.

PGHPF 2.3 Installed on Yukon

Version 2.3 of the Portland Group's High Performance Fortran has now been installed on Yukon, ARSC's T3E. Access to PGHPF is through the module command:

   yukon> module load pghpf

An online reference and user manual can be found through the compiler description at:

http://www.pgroup.com/hpf_comp_desc.html

and users can also find information about HPF in general at:

http://www.crpc.rice.edu/HPFF/home.html

and a useful HPF book is the High Performance Fortran Handbook, Koelbel, Loveman, Schreiber, Steel, and Zosel, ISBN 0-262-61094-9.

Please address all questions concerning this product to consult@arsc.edu or 907-450-8602. Users who encounter problems or wish to consider the performance of their codes on the ARSC T3E system are encouraged to contact consult@arsc.edu.

Quick-Tip Q & A

A: {{ Assume you have dozens of source files, many of which reference
      the same global variable.  You decide to change the name of that
      variable.  Is there an easy way to do this?  }}
  
   # To change all instances of "OLDNAME" to "NEWNAME" in all .f and .F
   # files in the current directory, the following command would work.
   # Word boundaries in perl regular expressions are matched by "\b", so
   # the command would (for instance) not change "BOLDNAME" to
   # "BNEWNAME".  If you were to replace the "-i" option with "-i.bk", 
   # then perl would make a backup of every file (giving it the 
   # extension ".bk") before changing it.
  
   perl -p -i -e "s|\bOLDNAME\b|NEWNAME|g;" `ls *.f *.F`
  


Q: Here's a proposed C assignment statement:

     ((buffer_cell->prev) ? buffer_cell->prev->next : buffer->cell) = 
        buffer_cell->next;

   Is this a good idea?  Self-documenting?  Is it even valid!?



A: {{ Bonus Answer!  From issue #124: 
      "How can one PE initiate an exit on all PEs?" }}

   # Thanks to the reader who reminded us of Cray's "STOP_ALL" 
   # subroutine.  This is a third, albiet non-portable, option.

[ Answers, questions, and tips graciously accepted. ]

Back to Top