Comparison of high-level computer programming languages

[Klystron]

For numerical calculations (as in a lot of scientific/physics programs), FORTRAN is reputed to be the fastest. It is targeted at those types of programs and avoids tempting features that tend to slow calculations down. I have not personally done tests to confirm that reputation of FORTRAN, but I have seen a few.

I have seen and conducted tests of FORTRAN computation modules including tests while performing real-time I/O. I've seen C++ test results running Mandelbrot sets (functions) on networked SGI's, even Crays. Agree with FactChecker and Alex. The CFD system design comes first. Choose language modules in the system for optimum function performance.

Once removed from the front-end interface which may be reading instruments or inputting data, and the fast computation intensive modules, computer speed measured in operations/time (flops, etc.) may not provide the best metric. Near-time analysis of function reliability and spot-check data integrity provides an "outer, slower" command loop sensitive to error. This outer command structure should not need to run at speeds comparable to computation but at the optimum frame rate for system control.

The statement "C programs call FORTRAN functions" though lacking meaning on a distributed network, captures the essential truth that both languages provide optimizations depending on use.

 

[FactChecker]

The statement "C programs call FORTRAN functions" though lacking meaning on a distributed network, captures the essential truth that both languages provide optimizations depending on use.

My experience with interfacing C and FORTRAN (and Ada) in scientific applications is that the matrix index swapping between column-major and row-major was a real hassle. Also the different array starting index (0 versus 1) was a problem. Those differences made the interface difficult and error-prone.

 

[Klystron]

Yes, not only indices. Suppose you have several different platforms performing computations with different significant digits (so to speak). Researcher expects to retain data commensurate with sampling uncertainty and within function restrictions. The programmer offers least significant digits among multiple processors?

Let's consider recursive subroutines. Given the restrictions on recursive functions can the programmer ensure reliable results across the network [here I'm involving "hardware"; i.e., "stack" issues not directly related to language selection.] depending on the computation.

[Edit: Speaking of boundaries, I've exceeded the scope of this thread about language selection. Norm]

 

[eachus]

My experience with interfacing C and FORTRAN (and Ada) in scientific applications is that the matrix index swapping between column-major and row-major was a real hassle. Also the different array starting index (0 versus 1) was a problem. Those differences made the interface difficult and error-prone.

I'm a bit confused. I used Ada and needed an Ada library to interface with a BLAS written in Fortran. I declared several types with
pragma Convention (Fortran, T_...); the T to indicate Transposed. The parameters of the BLAS routines used these types, and I provided functions to convert from one to the other: function Transpose(Arr: in T_Complex_Array) return Complex_Array; and the reverse. (Fun detail, the bodies were identical--in source). Also there was a procedure version to avoid copying of arrays. My only problem was that I spent the entire project wondering off and on about how to write the transpose functions. They were only called by debugging and test code, so in that sense it was a non-issue. But..

For a large matrix, keeping both locations in L1 cache is a big win, although you expect the writes to overwrite the contents of the cache line, you want the the cache line resident so it doesn't get read for each write. So:

procedure Transpose(A: in Float_64_Matrix; T_B: out T_Float_64_Matrix) is
-- parameter checking and non multiple of eight handling omitted for clarity.
  for K in 1..A'Length(2) loop
     for I in 0..(A'Length/8) -1  loop
       for J in 1,,8 loop
        T_B(I*8+J;K) := A(I*8+J;K);
       end loop;
     end loop;
  end loop;
end Transpose;

is much faster than the naive code--once arrays get large. Dividing the arrays into tiles that fit into 1/2 of L1D and transposing them should be a win, but I've never tried it.

 

[FactChecker]

Depending on what languages you are interfacing, the matrix transpose and changing the initial array index (0 or 1) may be necessary. There is additional complexity if some logic is looking at the indices and doing something with them. There are also cases where two languages are looking at the same data in shared memory or in a message and passing index information back and forth. It can get messy.
There are also cases where the data has more than two indices.

 

[bhobba]

For numerical calculations (as in a lot of scientific/physics programs), FORTRAN is reputed to be the fastest.

FORTRAN and C are equally as fast. But everyone knows programs spend most of their time in a small amount of code. You write in an easy to write language like Python, then a faster language like LUAJIT for the critical parts found from running the code. For example here is a quicksort in Python:

def qsort(arr):
if len(arr) <= 1:
return arr
else:
return qsort([x for x in arr[1:] if x < arr[0]]) + \
[arr[0]] + \
qsort([x for x in arr[1:] if x >= arr[0]])

Dead simple. But you may need it faster. I have written a quick-sort in assembler so I would hack that rather than use Lua or C - but that's just because I am lucky in having the code. It's not hard in Lua though - and if that isn't fast enough use assembler - but as I said I was lucky enough to have one in assembler anyway so would go for that.

In general you could go to C for the ultra critical bits, but I tend to go for assembler - JuaJIT is mostly as fast as C. And yes you still need a minimum knowledge of C - its excellent for gluing languages together, plus I don't write assembler direct but rather as assembler statements in C.

I learned FORTRAN 35 years ago and avoided it as much as possible since then - never did like it.

Thanks
Bill

 

[FactChecker]

FORTRAN and C are equally as fast.

That is what I always assumed, but the benchmark results that I have seen had FORTRAN slightly (but significantly) faster. I have no explanation for that and have never done my own comparison tests to verify it.

I learned FORTRAN 35 years ago and avoided it as much as possible since then - never did like it.

IMHO, even by today's standards, FORTRAN has some excellent features for scientific/engineering use that are unmatched in other general-purpose languages.

 

[bhobba]

Even by today's standards, FORTRAN has some excellent features for scientific/engineering use that are unmatched in other general-purpose languages.

It does with tons of libraries to call freely available. But I still reckon for real speed its assembler. No idea why FORTRAN would be bit faster than C, but personally I just use C as glue.

Actually in my degree I had to write some numerical analysis code - I had Pascal or FORTRAN to choose from - for me no choice - I used Pascal. As a professional programmer used a language called NATURAL, but after I retired moved onto Python and Lua. Do not know C that well - just use it for glue and in writing assembler. As usual assembler is a royal pain - but fast - really fast.

Thanks
Bill

 

[FactChecker]

Actually in my degree I had to write some numerical analysis code - I had Pascal or FORTRAN to choose from - for me no choice - I used Pascal.

When I was writing simulations of air-to-air combat, the ability in Pascal to write code like "ProbabilityOfKill( GoodGuy, BadGuy) = 0.5" where GoodGuy and BadGuy were enumerated types read as text from an input file was extremely appealing. Unfortunately, I was self-taught in experimenting with Pascal and there was no internet back then. I didn't know how to read/write a file of parameters containing enumerated types as text ( like "F16", "Foxbat", 0.5 ). I thought that it couldn't be done and left Pascal in disgust.

 

[Svein]

Way back when I started programming, the older guys were more or less married to FORTRAN IV. I did not care one way or the other until I had to debug a FORTRAN program - the error was that one instance of one variable was spelled wrong which made it an autodeclared variable which was never initialized but used in one particular spot.

Autodeclaration, three-way IF statements and hundreds of GOTOs - programming in assembly was less confusing.

 

[Alex Petrosyan]

I started coding with Pascal first. Nostalgia aside, it's not a very well-designed language. I really enjoyed C, where you had more fine control over memory allocation, and your strings could be of different lengths (and still be of type char*, unlike Pascal, where the length of the array was part of the type).

It's also a little too verbose. It's very good for a teaching language, but the smallest project I've been involved in, would be three times as large if it were written in Pascal.

Still love it thought. My first...