Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations biv343 on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Fastest Programming Language for Computational Purposes 1

Status
Not open for further replies.

tekvb1977

Technical User
Nov 16, 2005
46
US
WHat is the best language to adapt to for coding operations research algorithms:

FORTRAN
C
C++
JAVA

My main purpose is to intelligently select the language that would execute the algorithms and produce results faster than other languages.

I am kind of inclined towards C but not sure whether it's the right choice. Please help.

Thanks

J
 
The fastest and most efficent programs can be written in Assembly, but since that's like trying to learn Chinese I'd go with C/C++.
 
Well, with FORTRAN you write everything IN CAPITALS and no one will laugh at you.

It's also fairly efficent.
 
The big problem with C/C++ is multi-dimensional arrays. If you don't understand how to pass them in, you can screw up big time - just see how many threads we've had so far on multi-dimensional arrays. They always have problems creating them and passing them. OR is probably full of these so work out how you're going to pass them first. There is also the problem that some things are double and some are float. floats and doubles vary from machine to machine - some have double the range as well as resolution, others have double the resolution but not the range.

Fortran is a lot better on multi-dimensional arrays. There is a free F95 compiler from sourceforge. F95 can just about do everything that C can except for enums and macros. It also has features for parallel processing if your system/compiler supports it. Everything is real unless it begins with letters I..N. You can also use implicit double(a-z) in which case everything is double. It also has complex arithmetic built in.

Java is only fast if you compile as native. In its interpreted for, it is quite slow. It also relies on whatever version of Java Runtime you're running on your machine. If some utility (like Oracle) decides to update your version, it could just stop running. You could also have several versions on your box already without knowing about it. I've had occassions where Oracle wants one version and some other utility wants a completely different version

Is this just pure computation or do you need a GUI with it?
 
Thanks xwb for your elaborative e-mail. No, I wouldn't need GUI but I need to use lots of arrays (multidimensional) to code algorithms. I know FORTRAN but since it's so outdated in terms of syntax that I am leaning towards using C. However I don't want to make a poor choice by switching to C?

Can you recommend me any good book to learn C. I am doing programming in VBA and am very familiar with programming concepts like loops and arrays etc.

Thanks

J
 
Which part of "C multidimensional arrays are a pain" was not clear?
 
Re "C multidimensional arrays are a pain"

Static multi-dimensional arrays are fine except that they all begin at 0. Sometimes, it would be nice if the arrays had a range of say -2..2, otherwise you have to keep on adding offsets of create some macro which does the offsets for you.

Common mistake for someone coming from other language backgrounds: x[5,6] = 0
This sets x[6] to 0. 5, is just an expression which is legal in C. You won't get any warnings about this even though you meant x[5][6] = 0

Passing a 3D array as int*** can mean int[][][], int*[][], int []*[], int[][]*, int[]**, int*[]*, int **[] or int***. Throw const into the declaration and you'll have tons of variants.

Run it on one machine, it works brilliantly. Run it on another and it crashes miserably. You have to be very precise about what you are passing otherwise the compiler treats it any way it wishes.

Also, in C++, you can have int***& which will confuse the hell out of some C programmers.

The best way of declaring dynamic multi dimensional arrays is to treat it as a 1D array and allocate the 2nd and higher dimensions as pointers. Then run through lots of loops allocating pointers otherwise deallocating them is really painful.

 
I haven't used arrays higher than 2D, but I can't imagine why they would be painful to use? As long as you understand how C/C++ works, there shouldn't be a problem... If you don't know that arrays are 0 based then you'd have problems even with 1D arrays.

Also, dynamically allocating memory for arrays should be discuraged (especially for new C++ programmers) since it's likely they won't delete the memory or won't delete it properly. Multi-dimensional vectors would be my choice. But of course then you'd have to use C++ instead of plain old C.
 
Some might argue against this but sometimes vectors are faster , sometimes they are slower than arrays. I've got no idea why. I have yet to try multi dimensional vectors.
 
Item 46 in "Effective STL" by Scott Meyers gives an example of when and why using STL would be faster (sometimes MUCH faster) than doing it in plain C. It basically boils down to compiler optimizations and reductions in function pointer calls...
 
To me it is but someone else may have a different opinion.
 
Just so you know, I don't know FORTRAN at all.

A little something from the end of this page
Programmers tend to over-estimate the usefulness of the programs they write. The approximate value of an optimization is:

number of runs × number of users × time savings × user's salary
- time spent optimizing × programmer's salary
Now the first biggie is which languages do you know?

It's no use learning FORTRAN if some report or other says that it has a 10% advantage, if it takes you months to learn, and years to get good at it. Any naive programming on your part will soon erode any advantage there may have been, simply from not knowing how to use the language to it's best.

Consider how expressive the language is. C++ would seem to have the upper hand here. The STL allows you to focus more on the problem rather than the solution. For example, if you want a list in C++, just use the STL list container. In C, you'd have to write (or dig out from some previous project) a whole new list implementation (and debug it). Put bluntly, if you can write it in a week in one language, but it might take 3 months in another, does this affect your choice?

Also consider how long it takes to debug such a program - what tools are available to help you? Modern IDE's for C++ help you a great deal, are there similar feature rich tools for FORTRAN?

How easy is it to write bug-free code in the language of your choice?. C is notorious for having many traps for the inexperienced C coder, many of which can remain hidden for a long time.

With the exception of Java (as already noted), all the languages are compiled to native instructions for the target machine. In a like-for-like program, you're just not going to see orders of magnitude differences between one language and another.

Quite often, the easiest thing to do is wait for Moore's law to do it's bit and buy much faster hardware later on.


> The big problem with C/C++ is multi-dimensional arrays.
What an odd thing to say.
But given you said "Passing a 3D array as int***", I can see how you've always had problems.
Code:
#include <stdio.h>

void foo ( [COLOR=blue]int a[2][3][4][/color] );

int main ( void ) {
  int x, y, z;
  [COLOR=blue]int a[2][3][4][/color];
  foo ( a );
  for ( x = 0 ; x < 2 ; x++ ) {
    for ( y = 0 ; y < 3 ; y++ ) {
      for ( z = 0 ; z < 4 ; z++ ) {
        printf( "%d ", a[x][y][z] );
      }
      printf("\n");
    }
    printf("---\n");
  }
  return 0;
}

void foo ( [COLOR=blue]int a[2][3][4][/color] ) {
  int x, y, z;
  for ( x = 0 ; x < 2 ; x++ ) {
    for ( y = 0 ; y < 3 ; y++ ) {
      for ( z = 0 ; z < 4 ; z++ ) {
        a[x][y][z] = x + y + z;
      }
    }
  }
}
Passing arrays to functions in C or C++ is simple, you simply copy/paste the declaration of the array you want to pass to the function into the declaration/definition of the functions parameters (the blue bits). Not a '*' to be seen, and notice how the array syntax inside the function is exactly the same as the array syntax in main.

Some fussy compilers will no doubt warn you that the left-most dimension is immaterial, so you might need to edit the function down to this.
[tt]void foo ( int a[][3][4] );[/tt]

But that's all you should ever need to do.

Sure, if you want some stars, then you could write
[tt]void foo ( int (*a)[3][4] );[/tt]
but don't make the mistake of assuming this is in any way the same as
[tt]void foo ( int ***a );[/tt]
because it isn't.

Too many people get hung up on either equivalence, or assume that since arrays are passed as pointers that they have to riddle all their functions with pointer syntax.

--
 
It is all well and good if you know all the dimensions in advance but if you don't, you're stuck with the multi * syntax and all its problems.

If you don't know either language, does it make any difference which one you use? They'll both take just as long.

However, having said that, the big advantage of C/C++ is that there are lots of MVPs (whatever that means) to give you advice on how to code things. There aren't that many in Fortran.
 
Borland Delphi achieves the same computational speeds as
C++, but is very readable and that makes it easier to learn. The only problem with Delphi comes when you want to
use DirectX, because you'll need to translate the headers
first.

But like cpjust said, Assembly is the fastest language of
them all. It is also the most annoying of them all.

[bobafett] BobbaFet [bobafett]
Code:
if not Programming = 'Severe Migraine' then
                       ShowMessage('Eureka!');
 
I would say that the algorithms used have a far more impact on performance rather than the language used if you stick to compiled (not real-time interpreted) languages.

C++ is just as efficient as C, but much easier to use thanks to templates as long as you don't use virtual methods/polymorfism etc. Those features, though nice enough, are rather constly.

/Per

www.perfnurt.se
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top