C# – Converting Fortran 77 Code to C#

Back when FORTRAN was developed, there was no such thing as portability of code. It was absolutely routine for the FORTRAN compiler on one machine to accept a slightly different language that the compiler on another machine. The most common variation was name length. The IBM 1130 FORTRAN allowed five characters, the DEC-10 allowed six, the CDC 6600 (my first machine, my first real assembly language) allowed seven. Three-dimensional arrays were required by the language; at least one minicomputer (Varian 76?) FORTRAN allowed seven-dimensional arrays.

Companies routinely extended their FORTRAN languages, to make their machines more appealing to customers, and, while the extensions might provide similar functionality, they were never identical. Lots of compilers provided extensions for doing file I/O and overlay management, and they were never identical. Sometimes they weren't even close.

FORTRAN-to-FORTRAN conversions, porting a program from one machine to another, was a very busy cottage industry, and the guys who could do it could always find work. (I worked two such conversions: I helped port the original Matuszek-Reynolds-McGehearty-Cohen "Star Trek" game from the CDC 6600 to the DEC-10, and I ported an EKG analysis program from Varian 76 to TI 990. No two such projects were identical.)

This kind of thing made it very, very difficult to provide "standard" libraries, although a few people tried. The IMSL library was the biggest, but it was shipped in source code form, and the customer was required to get it working on his system.

Also: FORTRAN programmers were expected to have a reasonable background in numerical methods. Just about every FORTRAN programmer on the planet in those days learned how to do mean and standard deviation for himself, as a homework assignment. Every FORTRAN programmer learned bisection and Newton-Raphson iteration (nowadays called "Newton's Method") in school. Runge-Kutta methods were taught, usually by rote, and, at that time, 6th-order Runge-Kutta integrators were textbook examples. (It was much later that people figured out that 4th order Runge-Kutta was the "sweet spot" on the cost-effectiveness curve.)

And: Programmers RARELY changed computers without also changing jobs. Those programmers who did move around were expected AND REQUIRED to be very good at learning how the new systems worked, and picking up the differences.

In that environment, there's going to be very little call for a "standard" STDDEV code, when it was something that any competent entry-level FORTRAN programmer could write in his sleep.

IIRC one of the main reasons why Fortran is said to be faster is the absence of pointer aliasing, so they can use optimizations that C compilers can't use:

In FORTRAN, function arguments may not alias each other, and the compiler assumes they do not. This enables excellent optimization, and is one major reason for FORTRAN's reputation as a fast language. (Note that aliasing may still occur within a FORTRAN function. For instance, if A is an array and i and j are indices which happen to have the same value, then A[i] and A[j] are two different names for the same memory location. Fortunately, since the base array must have the same name, index analysis can be done to determine cases where A[i] and A[j] cannot alias.)

But I agree with others here: Comparing the average number of assembler instructions generated for a line of code is complete nonsense. For instance a modern x86 core can execute two instructions in parallel if they don't access the same registers. So you can (in theory) gain a performance increase of 100% for the same set on instructions just by reordering them. Good compilers will also often generate more assembly instructions to get faster code (think loop unrolling, inlining). The total number of assembler instructions says very little about the performance of a piece of code.