sorry, it is the same with me

I once (c. 1995) wrote a big thermochemical solver and then code to use the results. My preference at the time was C, but several of my colleagues scorned it. So I wrote FORTRAN and C versions of it so that I wouldn't get years and years of "you should have used FORTRAN, because it's known to be quicker" comments.

In the final analysis, it turned out that the difference between the two was pretty insignificant. I could gain say 10% speed by tuning it for one specific chip and then see that as a 10% loss on another similar chip. On average the FORTRAN was a few % faster than the C, although the error bars were for the most parts, overlapping.

I thought it was a clear indication that the language I chose to use had no significant effect on the speed. My colleague took the result straight to the boss, declaring a clear result that FORTRAN will always be the one true language.

Preconceptions. Data chosen to fit them. Not really sound engineering is it?

A few years ago in the very same forum there was a message where someone claimed that the c++ code runs 4-5 times slower than the fortran code. When the discussion heated up to its maximum he added an explanation: "Sorry, I did not realized that I was compiling C++ code with Visual Studio 'debug' option. If I compile it with 'release' option than fortran and C++ code run almost at the same speed." I think it would not be difficult to find this posting in archives. I am sure that you have chosen the right options for the two compilers, but just in case ….

Andy

When I was a child I thought that the quality of cars is measured by their speed. When I grew up the speed is the last thing in my mind when I am about to buy a new car. Still it is possible to remove heating, air-conditioning, and all seats and use the power we gain to increase car speed. But who would like to drive such car?

Andy

Besides being an impassioned discussion I'll give my personal opinion...

If someone are looking for a programming language able to do everything in a computer, things ranging from a simple program to sum two numbers to an entire operating system, this person should go through a C/C++, but, for most of the scientists that are only concerned in solving their physical, chemical and mathematical problems, Fortran should be the best choice. They must keep their minds focused in their problems and minimize problems with computing stuffs.

The main purpose of Fortran language is translated in its name, it is a very easy language to learn (even a child learn and make a program with Fortran in few hours), it is less error prone when programming than C/C++ with its pointers, and "cryptographic" sintax with all those simbols (<<,>>,? ==,+=,-=,++,--,}). In other words: a programming language easy, simple, fast and "clean" (only to solve calculations, of course).

I don't mind about Fortran being considered an old language or not, for my own purposes, Fortran is the best choice - no doubt about that! I've already tried to learn C/C++ many times... but I definitely give up. I only need to solve my CFD problems in parallel/vector HPC machines efficiently. For building GUI's and further ornamentation I can always use other language suitable to it.

I'll leave here another test between C/C++ and Fortran for others impassioned scientific programmers:

Write a code to solve a matrix-vector product and count the resulting number of lines. I'm almost sure that with Fortran it's possible to be done with at least 3 lines (at least with Fortran 90), what about C/C++?! Furthermore, after writing the first code, rewrite the same problem but with dynamic memory allocation ;-)

Regards

Renato.

Well, if you're working in a code that you and only you will use, you can work with fortran. But in a research group it's unlikely to happen. Besides that, most CFD researchers use 3rd party library for their solvers, so you just have to call them in your code. It takes 1 line, not 3 or 4.

When you're starting to learn C++, those "cryptographic" signals are a lttle confusing even if you're migrating from C to C++, but you get used to them. But I still think it's much easier to learn the meaning of <<, >>, ++ etc than to find the target label for a goto inside a program. In that sense, at least, C++ leads to a cleaner code than fortran.

Concearning performance, we always hear fortran people claiming that it's faster than C++. It was surely true in the 1990's, but the only numerical comparisons we saw previously in this discussion are those about blitz++ library. Maybe the blitz programmers used some optimization needed to improve the code speed, and it may not be necessary in fortran, but it has been shown that C++ can lead to fast math programs. And, if this is true, what is the problem? While C++ users and developpers work towards speed improvement, fortran people aim at object orientation with user defined types and so on. Maybe in a few years fortran allows data abstraction and templated codes. If this happens, would the fortran programmers leave this new fortran and work with fortran90 because it's easier?

It is only one line of code

Matrix a; // it is a class I define some ten years ago vector b, c; // can be user define or STL

c = a*b; // the main multiplication code

Can Fortran do it less compact?

Andy

Well,

Sorry, I should have said that I was not talking about using libraries. I was talking about programming by hand a matrix-vector product. Otherwise both programs could be done with BLAS routines and almost the same number of lines. Furthermore, in Fortran 9x, any compiler has the MATMUL intrinsic function to perform this task in only one line.

Pivello wrote: >> if you're working in a code that you and only you will use, you can work with fortran. But in a research group it's unlikely to happen <<

I work in a research group where everybody works with Fortran under CVS without any problem. I can't see where is the problem about working with Fortran in a researchig group, can you explain it better? Organization is not a programming language issue, it's due the programmer and the team group conventions. GOTO is optional in Fortran and discouraged in Fortran 9x codes, exactly because of the drawback pointed by you (loss of organization)

I think, in C/C++ is easier to make a confusing program than Fortran because all those "cryptographic" symbols, as I said, and all those include files, headers, bla, bla, bla. It's very easy to find a "C/C++ programmer" trying to find the right header for a specific operating system, to work with that library, etc, etc... to make his program working. Sorry but C/C++ seems to be a programming language for lazy people, starting by the name of the language (just "C").

As I said, it's an impassioned discussion. No doubt that C/C++ is the most powerful language available to do whatever we want in a computer. It's a very profissional language useful for those that really knows how to work with the language, but for calculations I can't see why people should learn C/C++ instead of an easy an suitable language to do it. Why do we need to "kill an insect with a nuclear weapon?"

Regarding the speed of the languages... no comments... it's an issue so hard to discuss that I can't comment. Machine, compiler, vendor, compiler optimizations, programmer optimizations, etc, etc... it's almost impossible to say which language is the fastest without defining a scenery. By this way, even a Java program could be the fastest ;-)

Regards

Renato.

Comparisons between the virtues of FORTRAN, C and C++ are always interesting. C clobbers F77 easily, no contest. C++ buries it.

F9x has copied load of C's better features in an attempt to keep the language's name alive, but I don't think it's fair to say FORTRAN when you mean F9x. I can recognise FORTRAN when I see it and F9x code using F9x features is nothing like FORTRAN.

Most FORTRAN programmers I know just use F77, with long variable names, long lines and lower case code.

Actually you can highlight the many problems that C++ has compared to "truer" object orientated programming languages such as ADA (see for example http://www.adaic.org/whyada/ada-vs-c/cppcv3.pdf)

Your main complaint about FORTRANs development from 77 to 95 can also be applied to the development of C -> C++.

I program both FORTRAN and C/C++ and it is a simple fact that for scientific programming FORTRAN is much better. On the other hand if I want to program something in opengl/x windows I tend to use C/C++ - the choice really depends on what you are doing!

yes, the two vers are "BOTH" on debug option

but remember both!!

It is not only a matter of change!!

the question is what is the best to deal with not the "new" trend that is growing up!!

Many programmers are working on VB6. IS VB6 a good programming lang for you, i don't thnk so

get it??

F77, F90, F95, F2003, it doesn't matter. They're all Fortran languages since you can use exactly the same sintaxe to program. Any Fortran compiler newer than F77 standard will certainly recognize the F77 sintaxe.

Fortran is much simpler than VB. Maybe this is a good argument againt VB. Nevertheless, I dont see any problem for using a linker. You can write your code in different programming langs. linking the resulting objs.

Maybe for a matrix-vector product, fortran is o.k. Large development requires much more, i.e. software engineering. It is hard to image a CFD solver based on a language which allows only low abstraction models. Using fortran, you will get a massive, spaghetty code using calling with an uncountable number of arguments. Maybe you can said that you can use F90, F95 or F03. I dont think that these Fx are ready for such a challenge. These can be used only as a support lang if really required.

question: How many CFD solvers are based on fortran? and How many new CFD developments are based on Fx, C, C++, Java, .. ?

answer: sorry, I dont know, maybe it can be interesting to find some numbers.

Tom wrote: >> I program both FORTRAN and C/C++ and it is a simple fact that for scientific programming FORTRAN is much better. On the other hand if I want to program something in opengl/x windows I tend to use C/C++ - the choice really depends on what you are doing! <<

I definitely agree with you!

I guess I should have made my main point clearer:

FORTRAN (i.e. real FORTRAN) does not allow dynamic memory allocation! Or pointers to memory and/or functions.

Other languages such as the current F9x breed and BASIC and Java and (quote your favourite modern language) may do. But as I've already stated, they are not FORTRAN.

FORTRAN 90 is FORTRAN just like C++ is C (i.e. they contain the other language as a subset).

You should check some of your facts as well. Firstly standard BASIC does not have pointers and secondly the use of pointers in JAVA is very different to that in C++ (in JAVA its the only way to reference an object which is OK since it's treatment of pointers is much better than that of C++ ).

>> I can't see where is the problem about working with Fortran in a researchig group, can you explain it better?

I wasn't talking about CVS, I was talking about templates and generic programming and so on, which are features that makes the code expansion much easier.

Syntax is just a matter of preference, you don't like >>, {}, maybe some one doesn't like .gt., .ne., etc. Header files only become a problem if you work with compilers that don't follow the standards. In C++ this problem happens mainly when you change your program from microsoft to other compilers, because MS doesn't follow the ANSI standard - at least didn't when I worked with it, but it's been some years since I moved to linux. Unless you're talking about computer graphics, but I never worked with it, so I can't say.

>>Sorry but C/C++ seems to be a programming language for lazy people How can it be a language for lazy people if you're just complaining about its complexity? You've just said that FORTRAN is best suited for numerics because of its simplicity... I didn't understand that.

I'm leaving this discussion, because, as we say here in Brazil, people shouldn't discuss politcs, religion or soccer, because it will never be a rational talk. It seems that we should add programming languages to this list.

- Márcio

Look at this:

for(j=0; j<=*ndim-1; j++){

k = j;

for(i=0; i<=*nnos-1; i++){

val = xyz[k];

fwrite(&val,sizeof(float),1,fg);

k += *ndim;

}

}

It can't be considered simpler than

write(iunit) (xyz(1,i),xyz(2,i),xyz(3,i),i=1,nnos)

or

write(iunit) ((xyz(j,i),j=1,3),i=1,nnos)

I know a bit of C/C++ (among other languages) but I can't figure out why should I go in the hardest way when programming. I think, simplicity and easiness are a bit different than what a "cryptographic" language provides (my opinion).

I only get a bit sad when I feel that people try to destroy the Fortran languages saying that it's old, limited, etc... It's my main point here in this topic. Unfortunately, we're forgetting some of the main purposes of the Fortran language. Make the computation as simple as possible for students and scientists as Windows do in the personal computing world. In this sense, be "simple" means cutting most of the fat that makes a programming language powerful but hardest to learn and use.

I recognize the power of C/C++ and gave my personal opinion regarding the language. It's too much for me in my main application CFD+HPC, it's sounds like using a "nuclear weapon to kill an insect" as I said. "the choice really depends on what you are doing", as Tom said. Furthermore, I don't mind which is the fastest, efficient, etc... it's almost impossible to say which one is the best in these issues

PIVELLO: << as we say here in Brazil, people shouldn't discuss politics, religion or soccer, because it will never be a rational talk. It seems that we should add programming languages to this list. >>

As a Brazilian too, I agree with you and we could include programming language, operating systems and many other things, but it these areas we're always tasting new things and regarding soccer teams I'll always be a Vascaino and never will taste to be a Flamenguista ;o)

Regards from a Carioca's friend ;-)

Renato.

Here we are. If both versions were compiled with debug option your comparison of speed is totally misplaced. You should be comparing debugging capabilities of two versions and not speed.. Debug version is always created with a huge overhead of memory and computing speed. The rule is the better is debugger the greater is the overhead. Visual Studio C++ has an excellent interactive debugger, so it is not surprising that it run slower. Your comparison shows that the debugging capabilities of your Fortran compiler are very poor.

If your really want to compare speed compile the two versions with an option "release" or "optimize for speed" and let us know an outcome.

Andy