History of High Performance Computing in Cambridge

Cambridge-Cranfield HPCF  > Information for Users  > Programming and Compilation

This web page contains general programming information. Programming information specific to each machine can be found on the follow pages:

• Franklin (SunFire 15K) programming guide
• Maxwell (Sun Opteron) programming guide

There are also separate pages on general I/O issues, mixed language programming and MPI.

Recommended Languages and Applications

The recommended languages for use on the HPCF are FORTRAN and FORTRAN90. Although C is supported, it is a difficult language for a compiler to vectorise, and so could run a factor of ten or more more slowly than FORTRAN on these systems. It is acceptable to use it for the non-intensive parts of one's code, either by calling one's own FORTRAN routines for the intensive parts, or by relying on the various libraries. Writing numerically intensive routines in C, and using C++ at all, are not recommended (the latter is likely to have portability problems due to vagueness in the standards). For more details see http://www.tcm.phy.cam.ac.uk/~mjr/C/

The use of libraries is strongly encouraged. BLAS, and NAG (documented by nag_help and nag_info) are available on both systems.

In order to simplify the management of the system we do not provide outgoing or incoming email (although local email does exist), nor are web browsers, news readers etc. provided. The very standard UNIX utilities such as sed, grep, awk etc. are fully supported, but we would advise against relying on anything more esoteric (e.g. gnuplot, perl). It may be here today, but gone tomorrow. Such utilities are better used on departmental systems for they can be difficult to port to the unusual architecture of the CCHPCF and anyway the machines could quickly become overloaded if everyone started running Netscape on them! If you feel you need another utility, do ask, and we may be able to provide.

General Tuning and Porting

It is hoped that anyone programming the CCHPCF machines will have good experience of programming on similar machines elsewhere. Although the CCHPCF does occassionally run courses, staff shortages prevent us from having a strong educational role. However, at the risk of repeating some very old and tired advice, we would like to make the following points:

• Stick to the standards: whether writing C or FORTRAN, religious adherence to the standard will ensure that your code ports easily without any surprises.
• Use libraries: the supplied libraries are freer of bugs and better optimised than most users' code.
• Code cleanly: it reduces the number of mistakes you will make, and makes it easier for others to assist you.
• Code cleanly: it greatly helps the optimising compilers do their job.
• Code cleanly: avoid mixing I/O and computation in the same loop.
• Avoid hard-coding the number of processors: when writing for parallel machines, the code should be designed to be runnable on different numbers of processors after a fairly simple recompile at most.
• Avoid 2**n strides: accessing array elements separated in memory by 2**n words produces progessively worse memory bank conflicts as n increases. Conversely, sequential access is very fast.
• Avoid bizarre use of pointers: using arrays to index arrays, e.g. A(I(J)), produces unprefetchable code, and will need machine-specific compiler directives to restore any hint of performance.
• Concentrate on the important bit: make sure you know where your code spends its time, and work on optimising that small area, or changing the algorithm used.

Also, always try to construct a simple, short task for testing and developing your code, preferably one which can be run on a short, fast turn-around queue. It is even better if the answer is already known, and it is highly recommended to run a small test case on two different systems and compare the answers. This will pick up a lot of memory overwriting problems which are otherwise difficult to spot.