ARSC HPC Users' Newsletter 278, September 26, 2003

Guy Robinson Departs For Distant Shores

ARSC MPP Specialist, and Research Liaison, Guy Robinson is leaving ARSC and his adopted home of Alaska, for England. He'll be sorely missed around here staff, users, and his co-editor.

The following lyrics were written by a local ARSC user, Jack Miller, to honor Guy on his departure. They may be sung with apologies to the composer of "Red River Valley"...

            Lament for Master Guy

From dear Fairbanks they say you are going We will miss your bright eyes and sly smile For they say you are taking the sunshine That has brightened our path for a while

Come and look at my code if you love me Do not hasten to bid me adieu But remember Fairbanks Alaska And the hacker dependent on you

Won't you think of the users you're leaving Oh how lonely, how sad it will be? Oh think of the fond heart you're breaking And the grief you are causing to me

As you go to your home by the ocean May you never forget those sweet hours That we spent in Fairbanks Alaska And the codes we debugged o'er the hours

And from Guy, on his last day:

I'd like to thank all the people at ARSC, UAF, and our users for all the friendship and providing so many exciting challenges over the past years. I'm sad I'll not be with you to share the fun with the new systems but will look forward to learning all about the adventure in the Newsletter.

Peak Performance on X1

If you've been reading this newsletter for a while, you may remember our "Holiday Challenge" issued in newsletter 210 (December 2000).

The goal was to write a code that didn't have to do anything but sustain over 1 GFLOPS on one 1.2 GFLOPS SV1 processor.

Guy Robinson was the only winner of the contest (see: issue 213 ) and his code has become an in-house benchmark, to assure us that a pure Fortran code--no assembly magic--can approach a processor's advertised limit.

It's nice to report that this code, which has been dubbed, "gflop," gets about the same percentage of peak on the X1 as it did on the SV1... This is with minor tweaks to parameters, and compiled at "-O3":

  Processor  Theoretical Peak "gflop" code   "gflop" percent of peak 
  =========  ================ =============  ======================= 
    SV1         1.2 GFLOPS     1.037 GFLOPS      86.4% 
    SV1ex       2.0 GFLOPS     1.734 GFLOPS      86.7%
    X1 (MSP)   12.8 GFLOPS    10.876 GFLOPS      85.0%  

Supercomputing 2003, Deadlines and ARSC Involvement

Early registration for SC2003 closes Friday, October 10.


ARSC staff will be busy at SC 03. Drop by our booth, of course, but also look for us presenting a tutorial, BOF, poster, and at SC Global.

  Vector Performance Programming

  Time: Monday, November 17, 8:30AM              - 12:00PM
  Speaker(s)/Author(s): Edward Kornkven (ARSC), Andrew Johnson (AHPCRC)
    This tutorial will provide an overview of the current state of the art
    regarding vector computer systems and their application to science. 


  Cray X1 Programming Environments and Experiences

  Chair:        Guy Robinson (ARSC/CUG)
  Time: Tuesday, November 18, 12:00PM - 1:00PM
  Rm #: 36-37


    This BOF will bring together those with an interest in programming
    the Cray X1.


  SX-6 Benchmark Results and Comparisons
  Presented by Tom Baring (ARSC) and Andrew Lee (ARSC)


Attend SC 2003 without leaving home!

SC Global 2003

  Here's how UAF/ARSC folks can participate in SC Global:
    November 18-20, 2003
    8:30am-1:30pm ADT
    room: Butrovich 109
    The SC Global 2003 program has two major thrusts: the content of the
    presentations and the technology required to produce the geographically
    distributed program. SC Global 2003 will feature presentations by
    speakers from 16 remote locations, 7 countries, and 5 sovereign tribal
    nations, distributed across 4 continents. We will link the Phoenix Civic
    Plaza Convention Center with Access Grid* nodes worldwide.
  For schedule of Access Grid events, go to:

    (Note: On this web page, all times are Mountain)
  Questions concerning ARSC ACCESS GRID EVENTS? Contact:
      Paul Mercer
      voice: 474-6110


Let us know what you'll be doing at SC, and we can pass it on through this newsletter...

ARSC Training Reminder

We're offering training many Wednesdays this fall. Next week, "Introduction to the Cray X1". For the schedule see:

Also starting next week is a weekly MPI course over the Access Grid:

  Parallel Programming with MPI

    Every Wednesday in October, 2003
         9am-1pm ADT
         room: Butrovich 109
    For details see: 

        (Note: on this web page, all times are Eastern Daylight)

New Logo for ARSC's 10th Anniversary

It's amazing the work that goes into creating a new logo and propagating it to envelopes, mugs, shirts, power-point slides, and, in case you're dying to see it right now, the web:

Quick-Tip Q & A

A:[[ I develop software in collaboration with other people. Each time they
  [[ have a new version I have to carefully study it for changes. Most of
  [[ them are small but important. I'm looking for ways to automatize the
  [[ parts of the process that do not require much thinking.
  [[ The best I found is to run the diff com and between files of the old and
  [[ new version, study the differences and manually write the new code.  Is
  [[ there a way to pipe the output of the diff command to a tool that would
  [[ let me more or less automatically reject or accept a change?

# Thanks again to the questioner, and to the four tipsters, below:

# Jed Brown

The mergemaster script for FreeBSD does exactly this and more. It was
designed for updating the /etc directory after rebuilding world, but can
be used for updating arbitrary directory trees very efficiently.  I
haven't used mergemaster on non-FreeBSD, but it is a standard /bin/sh
script and should work fine on any POSIX system. Available at (You
will probably want to grab both the script and the man page.)

# Greg Newby

For groups, the answer is CVS.  This lets people check in and check out
code, takes care of version control, and can handle minor conflicts (and
bring major conflicts to the attention of the submitter).

CVS uses RCS at the back end, which is a tool suitable for single-coder
projects.  There are some other tools similar to CVS, including
commercial software.  CVS is Unix-based, and uses a client-server model
-- I believe clients are available for MS-Windows, as well.

CVS is standard on Linux distributions, and available for others.
Setting up a CVS server is not hard, though a little complex.  Visit:

# Martin Luthi

Use a version control system such as CVS (classic) or Subversion
(sophisticated, yet not fully stable). This is also highly recommended
for your own files (Text, Programs) as you keep track of the evolution
of these documents.

# Nic Brummell

Use "cvs"!!!  Its a source code management system designed to do all the
things you desire and more.  I use it all the time.

Q: I logged onto your system and tried to compile my cpp program, as follows:
     cpp prog.cpp
   Why didn't it work?  

[[ 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