ARSC HPC Users' Newsletter 323, August 26, 2005

IBM: Compiler Upgrades

The latest versions of the IBM XL Fortran and XL C/C++ compilers have been installed on the debug nodes on iceberg for evaluation purposes. (The debug nodes can be accessed via the "debug" class.) Users are encouraged to compile existing codes with the new compilers to verify results are the same as those obtained using previous versions of the compilers.

The compilers will be upgraded on the remainder of the nodes on iceberg in October.


Debug Node Compiler Versions:
=============================
 * XL C/C++ 7.0
 * XL Fortran 9.1

Other Node Compiler Versions:
=============================
 * Visual Age C/C++ 6.0
 * XL Fortran 8.1

Below are some new features which are included in the latest compiler versions.


XL Fortran 9.1 New Features
===========================
 *  Improved support for Power5 systems.
 *  New suboption "-qflttrap=nanq" to detect and handle NaN values,
    including values not generated by invalid operations.
 *  The flag "-qsaveopt" saves the compiler options into the resultant
    object file.
 *  The flag "-qversion" will provide the version and release of the
    compiler.
 *  Enhancements based on the Fortran 2003 draft standard.


XL C/C++ 7.0 New Features
=========================
 *  Improved support for Power5 systems.
 *  New suboption "-qflttrap=nanq" to detect and handle NaN values,
    including values not generated by invalid operations.
 *  The flag "-qsaveopt" saves the compiler options into the resultant
    object file

For a complete list of new features, see the "XL Fortran 9.1 User's Guide" and "XL C/C++ Getting Started Guide" which are available at the links below:


 * 
http://www-306.ibm.com/software/awdtools/fortran/xlfortran/library/

 * 
http://www-306.ibm.com/software/awdtools/xlcpp/library/

Book Review: "Best Perl Practices"

[ Thanks to Lee Higbie for another book review! ]

Book Review: Best Perl Practices by Damian Conway, O'Reilly, $40.

"Best Practices" provides 18 chapters of rules for programmers and programming teams. Though its rules are for Perl programming, many are applicable to other languages and should be used by all programming teams.

Recommendation: A worthwhile scan for anyone programming in any language. If you are involved in a large programming project, especially one with a team of programmers, get this book and use the appropriate parts for all the languages you are using. Perl is more in need of style discipline than most languages, so even modest Perl programs will benefit by following the author's dicta.

Conway bases his 250 or so rules on three principles, which are relatively non-controversial:

  1. Make code more maintainable or readable, because even the code's author won't remember what he meant after a few months.
  2. Make code more efficient or faster executing.
  3. Make code more concise so it can be grasped more easily at a glance.

Conway's jaunty style makes this a readable book, though its prescriptive nature would suggest otherwise. Whether you agree with and use or ignore any specific rule, all programmers writing more than prototype code should at least consider his admonitions.

A good example is in his first chapter on code layout, an area where standard styles vary widely. His first rule is to use the Kernighan and Ritchie style of parentheses and braces for delineating blocks: Put the opening brace at the end of the line with the statement beginning the block and align the closing brace under the first letter of the keyword. This follows from principles 3 (saves a line) and 1 (we first notice the beginning of a line). The major omission from his rules is on the use of comments with blocks. Conway should also have prescribed a comment attached to ending brace of a block.

For example here are three standard loop layout styles: The recommended K&R style:


    for my $name (@names) {
        for my $word ( anagrams_of(lc $name) ) {
            print "$word\n";
        }
    }

I would strongly recommend comments on the two closing braces to make intended pairing obvious. I'd put "# end $name loop" after the last brace, for example. The bulkier BSD style takes two more lines of limited screen real estate:


    for my $name (@names) 
    {
        for my $word ( anagrams_of(lc $name) ) 
        {
            print "$word\n";
        }
    }

The bulkier GNU style takes more lines and columns and misaligns the closing bracket from its keyword:


    for my $name (@names) 
        {
            for my $word ( anagrams_of(lc $name) ) 
                {
                    print "$word\n";
                }
        }

Like many of his rules, this one applies to many programming languages. Conway advocates 4 space indentation as above, always with spaces not tabs, as a good compromise between readable indentation and keeping lines short enough to be visible on a screen.

Conway dictates using loop labels for any loop with the perl next, last, or redo statements. In Fortran, this recommendation applies to the "exit" statement, as in this example:


   name_search_loop: do i = 1, list_length
       if (name .eq. list(i)) exit name_search_loop
   enddo name_search_loop        ! end i loop
  

I have added the labels and comment to the enddo, a part of my own recommendation on loop clarity. Here the label is unnecessary and some would argue that the loop label obscures the beginning of the loop, but Conway points out that maintenance is simplified because another loop can be added inside this loop without affecting the exit.

On documentation, Conway stresses the importance of separating maintenance from user documentation. Using perldoc and perlpod to create user documentation from the file's text is generally going to produce better results than separate docs, and this is advocated. Perl includes documentation utilities that have enough smarts to know which other files to look for, but these additional files may not be available to an end user and they may not be found if present. Documentation that is included with the code, in the .pl or .pm file for Perl, will always be available to users.

In addition to my rule about comments at block ends, I would add one more rule to Conway's collection. Make the length of variable names proportional to the size of their scope--temporary and local names should be short, global names should be long enough to be self-descriptive.

In sum, my recommendation: This is a good book for any programmer and should probably be required reading for any teams doing projects using substantial amounts of Perl.

LAPACK / ScaLAPACK User Survey

We received this email. It applies to you, if you're a LAPACK or ScaLAPACK user:


> The Sca/LAPACK team is planning on new developments for LAPACK and
> ScaLAPACK.  In order to prioritize the development tasks, the team has
> developed the following survey. We would like to ask you to take a few
> minutes and complete the survey.
>
>     See: 
http://icl.cs.utk.edu/lapack-forum/survey/

Final ARSC Summer Tour of '05, August 31st

According to a blunt friend of mine, the Fourth of July in Fairbanks is the first day of fall. Maybe yes, maybe no, but by now, the cranes are forming noisy flocks, preparing for the trip South, autumn is in the air, and ARSC Summer Tours are about to end.

If you're a returning student or have otherwise missed it, your last chance this SUMMER is next Wednesday at 1pm. For details:

http://www.arsc.edu/news/summer_tours.html

Quick-Tip Q & A


A:[[ It takes forever to untar my .tar file, and all I really need from
  [[ it is one file.  Has anybody written a tool to extract just one file
  [[ from a tar file?  This is really ridiculous!


#
# Thanks to Ed Kornkven:
# 

Maybe I'm missing something, but how about:

  tar xf archive.tar file_to_extract_1 file_to_extract_2 ...


#
# From Brad Chamberlain:
#

Here are two ways:

1) The gnu implementation of tar does support the ability to pull out 
   one file at a time.  As with most tar options, it looks like there
   are many ways to pull it off.  The way I like is to first check the
   contents using:

        prompt> tar --list -f <tar filename>

   and then using one (or more) of the names listed in the contents do:

        prompt> tar -x -f <tar filename> <filenames to extract>

   (where "x" is the normal tar mnemonic for extract -- there are more
   verbose flags that do the same thing).  One thing to note in doing
   this is that if the file has a relative path, it will be untarred to
   that location.  For example, if the contents listing yielded:

        src/foo.c

   and I extracted src/foo.c, it would be placed in a subdirectory named
   foo (which would be created if it didn't already exist).


2) As an emacs user, my preferred way is actually to use emacs.  In emacs,
   upon loading a tar file, I get a nice directory listing of the tar
   file contents.  Moving the cursor to one of the files and hitting the
   middle mouse button or the space bar extracts that file to a
   temporary directory and brings it up in an emacs buffer.  Usually, I
   find myself wanting to browse a tar file's contents, and this tends
   to be a much cleaner way to surgically go in, look at a file, and not
   leave it in some subdirectory when I'm done with it.

#
# More information from Greg Newby: 
#

Unlike some other formats, tar files don't have a single index with file
offsets.  This means that in order to find and extract a particular
file, the tar command needs to read through the tar file until it finds
it.

The bad news is that you will need to wait for your tar file to be read
until the file you wish to extract is found.  For a large tar file, this
can take awhile.

The good news is that you can tell tar to only extract the file you want
-- saving the need to write all the other files from the tar file.  So,
you can save on the amount of *writing* done, but you can't really avoid
*reading*.

If you had a tar file hello.tar with a file "asdf.txt" you could use
this syntax to extract just the file you want:

        tar xf hello.tar asdf.txt

#
# And finally, Kate Hedstrom demonstrates some Unix elegance:
#

I did this just today:

  gunzip < toms-ice.tar.gz 
 tar xvf - toms-ice/SeaIce/ice_bulk_flux.F



#### BONUS ANSWER: 

# A communication failure betwixt the editors led to the omission of
# Orion Sky Lawlor's answer to the previous question.  Here it is:

I've attached a little Bourne shell script I use for this 
task.  For this example, you'd call it like this:
        ./rename_sed 1234 4567 *1234*

You can use arbitrary regular expressions in the source and 
destination patterns, assuming you can get sed to do what 
you want with them!

######################################################################

#!/bin/sh
#
# Usage: rename_sed <src pattern> <dest pattern> <files...>
# Changes src pattern to dest pattern in each of the given
# file names.
#
# Orion Sky Lawlor, olawlor@acm.org, 2004 (Public Domain)
#

sedSrc="$1"
sedDest="$2"
shift
shift

for src in "$@"
do
        dest=`echo "$src" 
 sed -e 's@'$sedSrc'@'$sedDest'@'`
        if [ "$src" != "$dest" ]
        then
                echo " $src -> $dest "
                mv -i "$src" "$dest" 

 exit 1
        fi
done

######################################################################




Q: I have about 25 login names and passwords for various web sites I use.  
   The web sites include everything from free subscriptions and chat
   groups to (horrors!) on-line banking and investing.  The security
   required isn't at the level of my HPC accounts, but it's still
   important.

   A few practical suggestions for managing all these names and
   passwords would be appreciated.

[[ Answers, Questions, and Tips Graciously Accepted ]]


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