But the IBM RS6000 is famous for its great F77 compiler but lousy C compiler. On a x86 platform using gcc/g77, you might get very different trends. My advice on whether to choose C or F77 is as follows: if you really know what you're doing, coding things in C is preferable and will result in a faster executable. On the other hand, if you're a newbie at computer programming and have no intention of looking too deeply into algorithm optimization methods, then sticking to f77 is the best approach.

g77 only translates fortran to C++ and then compiles it with gcc. So it is NOT a fortran compiler. But, under linux, you can download a free demo of PGF77/PGF90/PGC++ and then compare the cpu time.

For my part, I use F90, because :

it's readable by almost everybody;

it's deal with allocatable memory.

Chears,

Sylvain

Sebastien your enthusiasm does you credit but...

Why do you believe the register hint in C will do anything in the presence of a reasonable optimiser? (in the early 80s perhaps but these days?).

Why do you believe that explicit function inlining is relevant to highly optimised Fortran code? (it is obviously relevant to C++ code but this is because the language has inserted vast numbers of function calls which are not present in the "equivalent" Fortran code).

Writing fast C++ code has nothing to do with science. It simply involves understanding all the things that cripple C++ performance and avoiding them. This has everything to do with learning what the compiler is doing in the background and almost nothing to do with the semantics of the language. It takes a very long time to master all this and then, at best, you have a vast amount of almost unreadable code which takes for ever to compile and occasionally matches the speed of Fortran but is generally slower.

Someone earlier suggested contacting the users of C++ in CFD codes (Sebastien would seem to qualify here!). I would modify that and suggest you contact the developers of the C++ numerical libraries/systems on which any serious attempt to use C++ would depend. I did this a few years ago when I had overcome my initial enthusiasm for C++'s obvious attractions and began to recognize its vast number of less obvious problems.

Bernard,

Do you seriously suggest that IBM cannot write a very efficient C compiler for their own processors? The suggestion is daft.

> On a x86 platform using gcc/g77, you might get very different trends.

If getting pretty much the same performance qualifies as a very different trend then we are in agreement. But this has little to do with the difference between efficiently compiling C and Fortran codes in general. A CISC processor with a small cache, slow memory access and fast processor clock speed is going to run a large numerical code at pretty much the same speed regardless of language (unless the language does not support arrays of course). This is pretty much guaranteed if the Fortran compiler does not include Fortran-style array optimisations.

Straightforward computation on arrays in C is never going to be faster than Fortran using reasonable optimising compilers.

A bit of clarification. There are two gnu Fortran 77 compilers on Linux.

(1) fort77 is based on the f2c Fortran->C translator. This parses Fortran fairly accurately but obviously cannot respect the more subtle requirements of the Fortran language. The resulting C code is slow and usually benefits from a bit of work to remove a few unnecessary overheads.

(2) g77 is a separate Fortran front-end for gccs general back-end. It seems a little less accurate at parsing Fortran but produces a bit faster code. It does not produce code to match a native Fortran compiler. The project has not been particularly active since the main developer gave up a year or two ago.

Which one you get when typing f77 seems to vary between installations but most recent installations will run g77.

>> Do you seriously suggest that IBM cannot write a very efficient C compiler for their own processors? The suggestion is daft.

Nope it isn't. Why would IBM write an efficient C compiler if most of the AIX users only use Fortran? Besides, the F77 compiler might be optimized for CFD-style computing on the AIX while the cc compiler might be written simply to compile the kernel and apps. I don't know what the reason is, but definitely, cc on AIX is below-par. Our 5 year old RS-6000 using cc is 2 times slower than a 5 year old PC running gcc (and the IBM machine cost at the time 20 times more than the PC..)

>> Straightforward computation on arrays in C is never going to be faster than Fortran using reasonable optimising compilers.

And I see no reason why straightforward computations on arrays in fortran should go any faster than in C, if the programmer _really_ knows what he is doing and optimizes the loop manually. The obvious advantages of using C are (1) the incredible free support out there on the mailing lists, and (2) the assurance that everything can be done in C, since pretty much anything of any importance is coded in C..

I saw a posting on a mailing list once that went along those lines:

LOGO is for children

PASCAL is for students

FORTRAN is for scientists

but C, however, is for programmers.

The fact that fortran is not even taught part of a normal CS curriculum speaks for itself. The language is dead, unsupported; good free compilers are unexistant; good commercial compilers are rare and costy. Plus, there's a bundle of fantastic debugging tools for C/C++ (like Purify or Insure++) that are simply unavailable for other languages. Not to mention that entire operating systems were built in C for C (like UNIX). Using UNIX while not using C is a bit similar to driving a car while refusing to shift gears: you miss out on a lot of functionality.

Once you get used to working with C (and I mean here the entire working environment, not just the language), you realize there's just no comparison possible with other languages: C is in a class of its own.

Just my two cents,

cheers,

bern

>> Why would IBM write an efficient C compiler if most of the AIX users only use Fortran?

Ummm, let me guess. Because almost every program on the computer is written in C? Because they want to sell the computer? (and I doubt very much if most users of AIX use Fortran).

>> I don't know what the reason is, but definitely, cc on AIX is below-par. Our 5 year old RS-6000 using cc is 2 times slower than a 5 year old PC running gcc (and the IBM machine cost at the time 20 times more than the PC..).

This is not a persuasive argument. Why not install gcc on your AIX system? Now that would establish if IBM can write a C compiler for their own hardware.

>> And I see no reason why straightforward computations on arrays in fortran should go any faster than in C, if the programmer _really_ knows what he is doing and optimizes the loop manually.

Unless you learn why an array is different in C and Fortran and the consequences for optimizing array expressions then we are agreed: you are not going to see the reason.

>> Once you get used to working with C (and I mean here the entire working environment, not just the language), you realize there's just no comparison possible with other languages: C is in a class of its own.

Now here we have full agreement. C was designed 30 years ago as a systems language and is in a class of its own. It's problems are well recognized by language designers and, as far as I know (excluding derivatives), no-one has suggested a new language that bears much resemblance to it since.

>> Ummm, let me guess. Because almost every program on the computer is written in C? Because they want to sell the computer? (and I doubt very much if most users of AIX use Fortran).

They don't have any choice: the combo C/AIX sucks big time ;-).

>> Unless you learn why an array is different in C and Fortran and the consequences for optimizing array expressions then we are agreed: you are not going to see the reason.

I admit my ignorance but why don't you tell me: I might learn something from your comments. No matter how Fortran manages its arrays, I'm sure there's a way of implementing the same approach in C somehow, whether this is at compile-time through an optimization flag or in the code directly.

>> Now here we have full agreement. C was designed 30 years ago as a systems language and is in a class of its own. It's problems are well recognized by language designers and, as far as I know (excluding derivatives), no-one has suggested a new language that bears much resemblance to it since.

The fact that it's been around for so long while not being altered significantly and still being used everywhere is an argument in favour of it, not against it.

I think it's quite clear we are both strong believers of different religions, and religious wars are rarely solved through arguing. But let me just clarify slightly my position on the subject: I'm not a die-hard fan of C: my favourite language is actually Pascal which I find to be the most appropriate for scientific programming. But the point I want to make is this: everybody uses C. The best coders in the world are using it. The same best coders wouldn't even know how to write ``hello world'' in fortran. They must have a reason, don't you think? So far, on the x86 patform, I was always able to match and surpass slightly in raw speed a F90 or F77 code, with very little changes to my C coding. I've been delighted with the generality of C and how easy it is to extend the functionality of my program. Even if C would be significantly slower than Fortran, I'd still recommend it if you plan on doing CFD development. A more versatile language leads to the possible implementation of a wider range of algorithms.. Some CFD algorithms I'm implementing now in C would be impossible to implement in F77, for example.

Anyway, that's just my opinion.

>> I admit my ignorance but why don't you tell me: I might learn something from your comments.

See earlier posting (the one with the web link) and follow the link.

>> No matter how Fortran manages its arrays, I'm sure there's a way of implementing the same approach in C somehow, whether this is at compile-time through an optimization flag or in the code directly.

See earlier comment on C99 and follow the web link.

>> The fact that it's been around for so long while not being altered significantly and still being used everywhere is an argument in favour of it, not against it.

Partially but in the same way as the wide spread use of Microsoft Windows is an argument in favour of using Micrsoft Windows. It says nothing about the competence of the language/OS except that it provides the minimum to get the job done (some might even dispute that).

>> I think it's quite clear we are both strong believers of different religions, and religious wars are rarely solved through arguing.

No, I would take offence at describing knowledge as religion. Religion requires signing up to a fundamental belief - C++ is the answer so what is the question? I have spent 10 years studying C++ to become a "guru" and now I am going to use it! - this is religion. Poking such people is not religion it is just teasing.

>> But the point I want to make is this: everybody uses C.

Yes.

>> The best coders in the world are using it.

Only when it is the appropriate choice. I would suggest this is not most of the time. (If you want to see the choices of skilled programmers then look at the results of coding competitions - results using C/C++ are poor and there are no entries using Fortran).

>> The same best coders wouldn't even know how to write ``hello world'' in fortran.

They would if a significant part of their task was scientific numerical analysis and the main language did not implement arrays efficiently.

>> They must have a reason, don't you think?

Yes. Scientific programming which once significantly shaped the development of the computing industry is now virtually an irrelevance to it.

>> So far, on the x86 patform, I was always able to match and surpass slightly in raw speed a F90 or F77 code, with very little changes to my C coding.

Yes. Fortran, C, Pascal, ADA, etc... I would expect to perform about the same for array based computing where the bottleneck is waiting for information from memory.

>> (1) fort77 is based on the f2c Fortran->C translator. This parses Fortran fairly accurately but obviously cannot respect the more subtle requirements of the

Fortran language. The resulting C code is slow and usually benefits from a bit of work to remove a few unnecessary overheads. <<

I strongly disagree with you on that point. Recently, I had to implement a new solver in a MHD code written in fortran. In order to compile it on my FreeBSD (UNIX) PC, I used f2c with gcc and time the code. My client uses Digital Fortran on a WinNT station, and in order to make sure that the code will always work for his workstation, I always do a compilation with my PC rebooted with win98 and Digital Fortran. For both compilations, I always used the best flags for optimization. Beleive it or not, the computational time on both Systems is the same.

Try turning down/off the optimisation. Is the time still the same? Now what do you conclude?

yeah, I'm a C programmer when i program but my limited exposure to Fortran90 has made me realize that it's probably better for number crunching plus it's easier and you can be lazy (and still be efficient) if your writing code to do small things.

when I say "Fortran" I mean F90. I think you could defintely outdo F77 with C or C++. However I think if you matched a C/C++ programmer and fortran programmer of equal skill the C guy would be hard pressed to gain the advantage compilers being roughly equal.

Personally I think the IBM C compiler is quite good and the features are quite similar between it and the F90 compiler. If I'm not mistaken the GNU F77 compiler translated F77 to C then compiles it (?). If that's true then by default the F77 code wouldn't likely be faster