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:- 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)
- Different clock granularities for gettimeofday (Newsletter #11)
- Restrictions on record length for direct I/O files (Newsletter #19)
- Implied DO loop is not "vectorized" on the T3D (Newsletter #20)
- Missing Linpack and Eispack routines in libsci (Newsletter #25)
Current Editors:
E-mail Subscriptions:
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
-
Subscribe to (or unsubscribe from) the e-mail edition of the
ARSC HPC Users' Newsletter.
-
Back issues of the ASCII e-mail edition of the ARSC T3D/T3E/HPC Users' Newsletter are available by request. Please contact the editors.