ARSC T3D Users' Newsletter 27, March 17, 1995

News from CUG

Last week, March 13th to 17th was the annual North American CUG meeting held this time in Denver Colorado and sponsored by NCAR. It was a tremendous meeting for T3D users as there was a T3D conference running concurrently with the CUG meeting. This conference was called SPAD (Scalable Parallel Application Developers conference) and was put on by the CRI PATP (Parallel Applications Technology Program). Between the CUG presentations and the SPAD talks there were over 27 hours of presentations about the T3D. In the upcoming Newsletters I'll go over some of the results from this CUG meeting. Unfortunately, there are no plans to publish the SPAD material as part of the CUG proceedings but CRI may eventually make this material available on the CRI web server.

Managing the Memory on a T3D PE

The following is a article printed in the Cray Research Service Bulletin that appeared in July of last year. I think it is an important article but I didn't get a copy of it until this month.

  > Determining static memory requirements for CRAY T3D executable
  > files
  >  
  > Systems:     CRAY T3D
  > OS:          UNICOS MAX
  > Product:     Commands
  > Audience:    Programmers
  > Date:        July 1994
  >  
  > Starting with UNICOS MAX version 1.0.0.8, a new command, mppsize,
  > prints out the segment sizes for CRAY T3D executable files. The
  > output from mppsize lets users determine the static memory
  > requirement for their CRAY T3D executable files.
  >  
  > For background, each CRAY T3D processor element's (PE's) memory is
  > divided into different segments. The following segments are of
  > interests to this topic:
  >  
  >  *  The code (or text) segment that holds the program's (both
  >     application and system libraries) instructions for the executable
  >     file. 
  >  
  >  *  The private data segment that holds the program's private data for
  >     the executable file, such as initialized local data (with Fortran
  >     data statements and Fortran common blocks (both initialized and
  >     uninitialized)). 
  >  
  >     The private data segment also includes the initial default
  >     private heap size of 786,432 bytes. This heap space is managed
  >     dynamically during run time, grows toward higher memory, and
  >     holds data such as Fortran automatic arrays or I/O file
  >     structures. You can reset the initial default heap size by using
  >     mppldr command options.
  >  
  >  *  The private stack segment, which has an initial default size of
  >     786,432 bytes (C0000 hexadecimal), holds local variables and calling
  >     sequences data. Like the heap, the stack also is managed dynamically
  >     during run time, and its initial size can be reset with mppldr
  >     command options. Unlike the heap, the stack grows toward lower
  >     memory. 
  >  
  > The following shows the logical layout of these segments in
  > memory:
  >  
  >  
  >                          
           ...             

  >      6000000000          
---------------------------

  >                          
  PRIVATE STACK SEGMENT  
 

  >                          
                         V 

  >                          
---------------------------

  >                          
                         ^ 
 
  >                          
       PRIVATE HEAP      
 

  >                          
---------------------------

  >                          
                           

  >                          
   PRIVATE DATA SEGMENT    

  >                          
                           

  >      4000000000          
---------------------------

  >                          
                           

  >                          
       CODE SEGMENT        

  >                          
                           

  >      2000000000          
---------------------------

  >                          
           ...             

  >      0000000000          -----------------------------
  >  
  >  
  > The following example shows how to use mppsize:
  >  
  > /tmp/test => cf77 -X1 test.f
  > /tmp/test => /mpp/bin/mppsize a.out
  >  
  > The following shows sample output from mppsize:
  >  
  > *************************************************************************
  >  
  > Startup program is:     #!/mpp/bin/mppexec
  >  
  > Number of PEs:           1 (fixed)
  > OS partition required?  no
  > H/W partition required? no
  >                barriers: 1
  >                 eurekas: 0
  > Shape hint (0,0,0)
  > Transfer address:       2000000000
  >  -----------------------------------------------------------------------------
  > Segment                   Size T S P G A L     D  Disk   Length   Offset Zeroed
  > 2000000000          code B1DA0 T N 5 0 N 0     0   570    B1DA0        0      0
  > A000000000   shared data   C50 D Y 6 0 N 0  4C50 CE268        0        0    850
  > 4000000000  private data DE280 D N 6 + N 0 E2280 B2310    1BF58        0   2328
  > 6000000000 private stack C0000 S N 6 - Y 0 C4000     0        0        0      0
  > 8200000000     registers     0 R N 6 0 N 0     0     0        0        0      0
  >         Symbols                                   CE268    23B58       0
  >         Dot o's                                       0        0       0
  >      Directives                                       0        0       0
  >    843000 (decimal) bytes will be initialized from disk.
  >    146264 (decimal) bytes are required for the symbol table.
  >      1392 (decimal) bytes are required for the header.
  >    990656 (decimal) bytes total
  >  
  > *************************************************************************
  >  
  > The hexadecimal numbers under the Size column are the most
  > important to our current topic. To run on CRAY T3D systems, the
  > application (or executable file) needs the number of bytes (in
  > hexadecimal numbers) for each of the corresponding memory
  > segments listed (the code, shared data, private data, and private
  > stack rows).
  >  
  > Also, the Disk, Length, and Zeroed columns indicate that a record
  > of Length bytes will be loaded into the PE memory from disk
  > beginning at byte offset Disk, and the Size for the segment will
  > be initialized to 0 for a Zeroed number of bytes (BSSZ space). To
  > calculate the uninitialized data (or BSS) space, use the
  > following formula:
  >  
  > Size = Length + Zeroed + BSS  =>  BSS = Size - Length - Zeroed
  >  
  > Therefore, the code that produced the preceeding mppsize output
  > has the following static memory requirements:
  >  
  >     Segment       Size (hexadecimal)    Size (decimal)
  >     -------       ------------------    --------------
  >  
  >          code           B1DA0              728,480
  >   shared data             C50                3,152
  > private data            DE280              909,952
  > private stack           C0000              786,432
  >  
  >  -------------       ---------          ----------  
  > in bytes:              250C70            2,428,016
  > or in 64-bit words:     4A18E              303,502
  >  
  > The requirements include an initial default size of C0000 (or
  > 786,432) bytes for each of the private heap (included in the
  > private data segment) and private stack. Because the operating
  > system will increase the heap and stack space automatically (with
  > system calls) if required during run time, you can use mppldr
  > command options to lower this default size to reduce the initial
  > static memory requirement for larger applications.
  >  
  > For example, you can set the initial size of the heap and stack
  > to 65,536 bytes by using the following commands:
  >  
  > /tmp/test => cat > segdir
  > heap=65536
  > stack=65536
  > /tmp/test => cf77 -X1 -Wl"segdir" test.f
  > /tmp/test => /mpp/bin/mppsize a.out
  >  
  > Which produces the following:
  >  
  > *************************************************************************
  > Startup program is:     #!/mpp/bin/mppexec
  >  
  > Number of PEs:           1 (fixed)
  > OS partition required?  no
  > H/W partition required? no
  >                barriers: 1
  >                 eurekas: 0
  > Shape hint (0,0,0)
  > Transfer address:       2000000000
  >  -----------------------------------------------------------------------------
  > Segment                   Size T S P G A L     D  Disk   Length   Offset Zeroed
  > 2000000000          code B1DA0 T N 5 0 N 0     0   570    B1DA0        0      0
  > A000000000   shared data   C50 D Y 6 0 N 0  4C50 CE268        0        0    850
  > 4000000000  private data 2E280 D N 6 + N 0 32280 B2310    1BF58        0   2328
  > 6000000000 private stack 10000 S N 6 - Y 0 14000     0        0        0      0
  > 8200000000     registers     0 R N 6 0 N 0     0     0        0        0      0
  >         Symbols                                   CE268    23B58       0
  >         Dot o's                                       0        0       0
  >      Directives                                       0        0       0
  >    843000 (decimal) bytes will be initialized from disk.
  >    146264 (decimal) bytes are required for the symbol table.
  >      1392 (decimal) bytes are required for the header.
  >    990656 (decimal) bytes total
  >  
  > *************************************************************************
  >  
  > And the following static memory requirement:
  >  
  >     Segment       Size (hexadecimal)    Size (decimal)
  >     -------       ------------------    --------------
  >  
  >          code           B1DA0              728,480
  >   shared data             C50                3,152
  > private data           2E280              189,056
  > private stack           10000               65,536
  > +                     
  >  -------------       ---------          -----------  
  > in bytes:               F0C70              986,224 
  > or in 64-bit words:     1E18E              123,278
  >  
  >  
  > The mppsize command requires mppldr version 10.e or later for
  > single-PE code and version 10.h or later for code that has shared
  > data.<end of article>
  > 
  > 

ARSC T3D Future Upgrades

We are testing the upgrade to the T3D 1.2 Programming Environment (libraries, tools and compilers.) If all goes well it will be on the system in one week.

We are also planning to install CF90 and C++ for the T3D. This will come after the upgrade to the 1.2 P.E. I am interested in hearing from users who want to use the CF90 and C++ products as soon as they are available.

List of Differences Between T3D and Y-MP

The current list of differences between the T3D and the Y-MP is:
  1. Data type sizes are not the same (Newsletter #5)
  2. Uninitialized variables are different (Newsletter #6)
  3. The effect of the -a static compiler switch (Newsletter #7)
  4. There is no GETENV on the T3D (Newsletter #8)
  5. Missing routine SMACH on T3D (Newsletter #9)
  6. Different Arithmetics (Newsletter #9)
  7. Different clock granularities for gettimeofday (Newsletter #11)
  8. Restrictions on record length for direct I/O files (Newsletter #19)
  9. Implied DO loop is not "vectorized" on the T3D (Newsletter #20)
  10. Missing Linpack and Eispack routines in libsci (Newsletter #25)
I encourage users to e-mail in differences that they have found, so we all can benefit from each other's experience.
Current Editors:
Ed Kornkven ARSC HPC Specialist ph: 907-450-8669
Kate Hedstrom ARSC Oceanographic Specialist ph: 907-450-8678
Arctic Region Supercomputing Center
University of Alaska Fairbanks
PO Box 756020
Fairbanks AK 99775-6020
E-mail Subscriptions: Archives:
    Back issues of the ASCII e-mail edition of the ARSC T3D/T3E/HPC Users' Newsletter are available by request. Please contact the editors.
Back to Top