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.
Tutorial: Vector Performance Programming Time: Monday, November 17, 8:30AM - 12:00PM Speaker(s)/Author(s): Edward Kornkven (ARSC), Andrew Johnson (AHPCRC) Abstract: This tutorial will provide an overview of the current state of the art regarding vector computer systems and their application to science.
BOF: Cray X1 Programming Environments and Experiences Chair: Guy Robinson (ARSC/CUG) Time: Tuesday, November 18, 12:00PM - 1:00PM Rm #: 36-37 Description: This BOF will bring together those with an interest in programming the Cray X1.
Poster: 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 Description: 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: http://www.sc-conference.org/sc2003/global.html (Note: On this web page, all times are Mountain) Questions concerning ARSC ACCESS GRID EVENTS? Contact: Paul Mercer voice: 474-6110 email: email@example.com
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: http://alliance.osc.edu/mpi/osc.html (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 http://www.FreeBSD.org/cgi/cvsweb.cgi/src/usr.sbin/mergemaster/ (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: www.cvshome.org # # 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. http://www.cvshome.org/ http://subversion.tigris.org/ # # 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 ]]
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.