Volume Number: 20 (2004)
Issue Number: 6
Column Tag: Programming
by Peter Amerl
With OS X, Apple unleashed a new tool upon the computing community that even Sir Isaac Newton would have been proud to use. Who knows, maybe he would have belonged to those in scientific computing who prefer to use the Unix command line interface, and the X windows interface. Or, maybe he would have liked the slick Mac interface, and its newly found flexibility. Either way, most scientific programmers whom I know (including myself) tend to use the command line interface since their input and output data are weighed in hundreds of mega bytes, and the code often massages and stores the reduced data, thus requiring only a very basic interface. Furthermore, coding for those in science is a means to an end (fame and fortune). Often it is necessary for scientific code to be portable, permitting development on the Mac while enabling compilation on the latest Teraflop Cray, or super cluster. This leads to my criteria for the evaluation of the NAG compiler:
The bulk of scientific computing is performed using two languages: C, and Fortran. Although C has evolved over the past decades with many new scientific libraries, abstraction layers in C++ simplifying the coding process, it is not always the best choice for scientific computing. Many solved computational problems are available on web sites such as http://www.netlib.org. A good fraction of these routines are coded using one of the Fortran flavors. Consequently, the language is likely to remain a scientific favorite for some time. The selection of third party Fortran compilers available for OS X is quite limited, and unfortunately, a good open source compiler for F90 or F95 is not available to date. Current third party contenders such as NAG F95, IBM XL Fortran, and Absoft ProFortran support compilation of source code for the F77, F90, and F95 standards. This review will discuss the NAG compiler for Mac OS X.
The Nag F95 compiler has a multitude of features, such as automatic file preconnection, IEEE 754 support, automatic garbage collection, memory tracing, undefined variable detection, a random number generator that is seeded based on the time of day, etc.. Yet this is all material that can be obtained from the usual propaganda sheets. Once I had the NAG compiler installed and functioning, the fun started. The compiler options are just what one would expect from a Un*x style Fortran compiler. The following options set it apart from other compilers. It can provide compilation feedback that is color-coded, so that compiler warnings, errors, and informational messages are displayed using different colors. This makes it easier to scan the resulting output for compilation problems. Support for conformance checking is included, although apparently only for the Fortran 95 standard. This conformance checking can be performed in the following ways: the compiler can provide warning messages on the use of extensions to Fortran, syntax that was deleted in the transition to F95, and obsolete syntax and commands. One superb feature that NAG provides with its Fortran compilers is runtime garbage collection that can be enabled with "-gc" during the link phase. In the past, the automatic garbage collection has saved me valuable system resources when a routine repetitively needed to allocate and deallocate a number of large dynamic arrays.
The compiler also accepts, and checks HPF directives, but unfortunately does not compile them into the executable. Through the lack of AltiVec (a.k.a. Velocity Engine) library support, it is clear that NAG created the compiler to serve as a general-purpose, platform independent tool. Mac G4 and G5 users must create wrapper functions in C++ to take advantage of the AltiVec routines, a situation that is less than ideal for those looking for Velocity Engine performance improvements. On the other hand, the lack of these additional functions makes the NAG compiler a good (foolproof) compiler to use for porting code to other platforms. An integrated development environment is not provided with the compiler, further gearing the compiler to command-line or emacs jocks (such as myself). At the time of this writing, the compiler was not designed to work with Xcode. This omission may not be a serious stumbling block as NAG does supply its own graphical debugger, upsf95, derived from the open source ups debugger. Information about it can be found at http://ups.sourceforge.net. I found the debugger to work much like graphical implementations of gdbg. For people with dual processor systems, a more serious omission is the lack of parallel processing support.
I suspect that the NAG compiler is still showing some teething pains. Upon installing the compiler on two systems, a dual G5 running Panther and a G3 running Jaguar, I immediately ran into trouble. On the G5, the compiler could not compile a "Hello World" program. Using the "ieee=full" compilation flag changed the executable favorably, but did not entirely fix the problem. In all fairness, I later found that the error occurred every time I compiled as the OEM user after allowing the system to go to sleep. On the G3 with OS X 10.2.8, the code would not compile under the OEM user. Magically, the problems disappeared when I created a non-administrative user account to compile and execute programs. It is possible the problems were caused by other software packages installed on both computers. After the initial frustration, the compiler ran smoothly. I could even compile and execute about 13000 lines of scientific Fortran 90 code originally destined for the SGI platform without problems.
Pros:
The compiler functioned well once its quirks were resolved. To me, the debugger felt much like a graphical version of "gdb" and was very usable. The compiler optimized the code noticeably well considering its lack of AltiVec support. The color-coded compilation messages are an excellent touch, and of great benefit to command line compilation. Most important to me, the garbage collection, and cross-platform compatibility functioned superbly.
Cons:
The lack of an IDE or Xcode compatibility forces the user to rely on other editors. Also missing is the ability to compile code for parallel processing. It appears that on some systems, the compiler can potentially act somewhat capriciously. Fortunately, using a non-administrative account with no additional software or haxies installed fixed code generation problems for me.
For anyone who has a favorite editor, and prefers to use make files, this compiler will be worthwhile. If Xcode integration is desired, the NAG F95 compiler is not the tool to use. Perhaps, with properly placed suggestions from users, NAG will support Xcode development in a future release. If you are looking for cross platform compatibility you will most likely also be well served. Before using the compiler I suggest the creating a clean user account. Once this is accomplished, run the compiler from within that account. In any case, this is an excellent practice for computer security.
Regardless of the compiler and operating system, the Apple Macintosh would not have been suitable for Sir Isaac Newton. It would likely have rendered him unconscious, or worse, as it fell on his head. Who knows, we might not know about gravity, or calculus, without Newton's contributions. Although most students would be much happier without these, it would also make present day computers unlikely.
Peter Amerl is a PhD physicist who has been coding scientific data reduction routines, and charged particle trajectory simulations for scientific instruments using Fortran 90 and 95 since 1996. Peter started his computing experience in 1982 with the Apple II+, eventually graduating to the Mac+. For a time of about seven years, he turned to the dark side until 1994, when the stability of Linux caught his eye. This fairytale continued until a wondrous discovery - OS X. Now Peter happily codes scientific routines on a G5.
