I am an experienced C/C++ programmer and a novice in CFD. While studying CFD and reading papers, I found most of them are implemented using Fortran 77/90 programming languages. One of the main reason is that in early days Fortran compiler is the only available compiler on most super-computers. Even today, Fortran code is still prevalence in CFD community.

When I asked some friends why they used Fortran instead of C/C++, the answer is: "This is the only programming language I know." Since most CFD student/engineers are usually not ordinary software developers and many numerical library are only available in Fortran.

***** QUESTION: What are the reasons to favor Fortran over C/C++? *****

Learning curve will be not steep for me, but it's a cost to switch to antoher programming language nevertheless - programmging style, debugger (if available) and libraries, etc. I don't have to do this except there are some very good reasons.

Thanks for your help.

I think there are no reasons other than the one you already mentioned: Most people in the established industry just don't know any better. By 'established', I mean major companies who have been around for some time. The newcomers, e.g. CFD startup companies, do use C/C++ extensively. At least this has been my experience at the last AIAA CFD conference in Anaheim, CA (June 2001) while talking to many company representatives.

I am an aerospace engineer and part-time shareware developer (see post a few lines below "MicroTunnel..."), and to me, personally, neither Fortran nor C/C++ has much appeal. I never enjoyed programming in Fortran, and I don't even like the syntax of C. To me the structure of C code is obscure with all those curly brackets around, or perhaps I just don't get it.

In my shareware programming, I feel I have combined the best of two worlds. I use VB (VisualBasic) for ease of creating the graphical user interface and output, and if I really want speed, I replace bottleneck subroutines with assembly coded DLL's, which I can call from VB like any other subroutine.

Unlike popular belief, VB is no longer just an interpreted or pseudo-code language (although p-compilation is still available for size optimization). Version 6, which has been around for some time, has a pretty good native code compiler, which allows for many speed optimizations, including options for the math coprocessor. In the past, I have written benchmark assembly routines like a bubble sort for integer and floating point arrays that would outpace the VB code 10 to 20 fold under VB4, whereas under VB6 the saving is less than 1%. For more complex data structures, however, such as the multi-dimensional arrays often used in CFD, VB is not the most efficient language (see my earlier post "MicroTunnel V1.2 - Now 6x faster), and I would be highly interested in a Fortran or C/C++ comparison of my flow solver code.

(1). It is identical to the reason why you are posting the message in English. (2). I am sure that in Taiwan, most people use Chinese MS Windows. Then it would take forever for English speaking users to understand it. (3). The actual machine code executed by the computer changes from computer to computer, from operating system to operating system, for compiler to compiler, even if you are using the same C/C++. (4). Even in VC++, there are many different ways to write the same code. (5). Computer language should be much simpler than taking a course at a college. They are all about the same, except there is a big difference in thinking, in terms of procedural and object-oriented approaches. (5). You don't have to write a code in Fortran, you can write it in C/C++.

(1). Try this one, and it should save you a lot of time in Fortran and CFD. "Applied Numerical Methods", by Brice Carnahan, H.A. Luther and James O. Wilkes. published by John Wiley & Sons,Inc, 1969. (the more recent edition could be published by other publisher? )(2). This is a "must have" book in Fortran. It has tons of theory, samples, flow charts, Fortran listings. It should also answer your question of "why".

A while ago, there was a discussion related to fortran and C (C++).

From my point these are the major reason why people favor fortran ov C/C++

1) Many of the folks who work in CFD only know Fortran...

2) Many of the codes have been started a while ago when the best compilers available were for fortan 77.

3) Many of the CFD people work with computers (Cray, Fujitsu, SGI, HP, Sun, IBM... ) that provide more than one CPU's. For these architectures, the best compilers available which can take advantage of the multi-processors architecture are fortran compilers.

But I wish to add that:

1) if you work with a one-processor architecture or a SMP architecture for which there are no multi-processor compilers, C, C++ or Fortran will offer roughly the same performance (even though I managed to get my C++ rouines run faster than Fortran routines...)

2) For codes that can be parallized with a message passing interface (such as MPI or PVM), I don't think a fortran program will be faster. For this case, C can be a better langage since these environements were mostly written in C.

...

Two good books:

High Performance Computing from K. Down and C. Severance (O'reilly)

Programming guide to fortran 90 from Brained, Goldberg, and Adams (Springler Verlag)

One thing that used to stated as an advantage for Fortran is the huge existing library of 'canned' routines, numerical libraries of lean, well-tested functions. Linear algebra, ODE integrators, sorts, even grid generators. Since these are for limited functions only and the Fortran language is now more-or-less standard, a well-written library routine doesn't even need to be rewritten to go from one computational box to another - machine independence.

Big emphasis on the 'well-tested'. I suppose these are being converted to C/C++ over time and a C programmer would probably convert a routine that he needed rather than learn Fortran (assuming he could read the Fortran well enough to convert it!).

I don't know enough about C++ to make a useful comment. I will point out that this is a somewhat useless debate, from a performance comparison standpoint, because performance so highly depends on the ingenuity of the programmer to develop clean, efficient data structures and write code which will compile into well optimised assembly language.

> 1) if you work with a one-processor architecture
: or a SMP architecture for which there
: are no multi-processor compilers, C, C++ or > Fortran will offer roughly the same
: performance (even though I managed to get my C++ > rouines run faster than Fortran
: routines...)

I always enjoy questionably useful comments like this, and especially when people publish their results. I guess you didn't spend enough time thinking about how to optimise your fortran subroutines then. Note that the inverse would apply if your result was the other way around.

Dan.

(1). The selection of a programming language in most cases has nothing to do with the performance of the code. (2). Historically, there was Fortran (Formula Translation) suitable for mathematical operations only. If you can write down a formula, you can easily write the Fortran code. It is almost one-to-one translation. (3). Then BASIC was developed as a teaching tool (for entry level programmers, engineer, scientist). It is easy to learn, and very slow to execute.(it is important for the entry level to use slow tools for obvious reasons) (4). Later, to handle more system programming, "c" was created. It was flexible enough, so most people in computer field use it. This is especially important for mini-computers and personal computers, because they have to deal with system problems. In the math operation part, "c" and "Fortran" are very similar. (5). That's about all, except that when "c" was extended to include the "object-oriented programming style", it became "C++". Officially, "c" is included in "C++" now. The extension of "c" to include the "class and object" make the new C++ somewhat confused. (6). So, it becomes somewhat difficult, only when people try to use the "class and object" portion. Otherwise, there is really nothing new. And one can still write in "c" style using "C++" compiler. (7). In some applications, such as computer graphics, it does make sense to use class and object concept to code the program. The same is true in business applications. (8). But since the use of class and object require extra work to allocate and de-allocate resources, it can slow down the calculation, if the performance is the goal. (8). But performance issue is rarely the major factor in selecting a programming language. Because, you will have to learn from existing codes, and add or modify the code. (9). The only reason to write a program is to document the process clearly, so that it can be read by the author himself or other people later on. The highly optimized code is nearly useless, because it is very hard to read, including the author himself. And a highly optimized code is useless in this rapid changing world. (even the hardware is changing in less than 3 months.) (10). For this reason, "C++" is good, because the class created can be re-used. I would say that performance issue is a personal issue, that is, it is a challenging task for individual.

I'm sorry Dan, but I took the time to optimize my fortran routines. These results were not meant for a publication. Furthermore, to actually get the C++ routines (mainly vector operations), I add to use programming practices only available with C++ ( explicit register variables). Without, this "trick", both langages offered roughly the same performances.

Regards.

There exists always the possibility to include fortran routines into C++ code. In my experience I have only really been able to get f77 code working in C++ programs but I am just a C++ beginner.

My advise to you is if you aready know C/C++ and are interested in CFD, learn FORTRAN simply for historical and code reuse issues.

(1). If a person is a professional programmer or a graduate from a computer science department, then I think, he should be able to write in different programming languages, learn easily new languages (new language usually takes a while to create), and have the training to create a new language. (2). If one does not know Fortran, he can not survive in CFD field at all.

Maybe you "think" you optimised your fortran, and that makes you feel good, but how do we know that you did a good job optimising it? How do we know that you are competent enough to properly optimise fortran? Maybe you are, maybe you are not. So, your comment is only anecdotal at best. I guess because of this I would personally never make any general statement that optimised C++ is faster than optimised fortran, or vice versa.

Just because your fortran was running slower doesn't mean you did the most efficient thing possible on whatever platform you were using. There could be a million different things wrong. Maybe you had your fortran compiled in debug mode by accident, maybe you didn't use the same compiler options, maybe you didn't use the most optimal compiler options, maybe you had a bunch of loops reversed (first index is the outer loop), maybe you didn't profile your fortran and C++ to identify bottlnecks, maybe you don't have decent data structures, maybe you didn't compare the assembly output of both compilers to address differences, etc.... there are so many variables.

Show me your C++, and show me your fortran if you want and I'll check it and reproduce your results for you. Then I would be convinced.

Dan.

Have had some experience with the languages mentioned. Each has it's strengths in different respects and in a project each can be used to perform the job it performs best. Why Fortran for sheer number crunching and fast handling? see: http://www.ibiblio.org/pub/languages/fortran/ch1-2.html

(1). I am sure that BASIC language is "slow". So, BASIC is not suitable for "number crunching" job. It is an order of magnitude slower than FORTRAN, c/C++. Otherwise, VB is very flexible and easy to use for Windows programming. It is very similar to Fortran language. (2). For "number crunching" job, I think, Fortran language is "pretty fast" and "easy to learn". Unfortunately, MS is no longer supporting Fortran language. So, I am no longer using it for program development on my PC. I think, it was the victim of the shrinking market in 90's. (3). For myself, I need to have the access to the Windows programming, 3-D graphics API or library and the speed, naturally. The only thing avaliable is VC++ from MS. (4). I am sure that there are Fortran compilers available for PC. So, it is not a problem to write a Fortran code on a PC. And I think, it really depends on "what you are trying to do with the language". In my case, the speed alone is "not good enough". I must have access to the Windows and 3-D graphic library. (5). And I don't think, CFD is all "number crunching". This could be the major factor in selecting a programming language.

1) As I said before, these simple tests were done on simple vector operations (dot product, addition, sclar product...) No profiling has to be done, these were simple one routine program.

2)As for outer-inner loops, these weren't matrix operations. Well, I know too well that for fortran the inner-outer loops have to be reversed compared to C or C++.

3) These tests were conducted on a linux box with the Gnu compilers (not the best available, I sould say..) using the same options.

4) As I said, in order to obtain better results with C++, I had to explicitly declare register variables. As a matter of fact, with an other compiler or another architecture (alpha, SGI..), the results could have been different.

5) If you use some profiling, I hope you are aware that you code will be highly optimised for a specific compiler and architecture. And this might not be the case for another platform.

6) My point is that I'm tired of hearing people saying that a fortran is faster. The truth is that the best langage for speed will depand on the compiler and the architecture.

7) As John said, the choice of a langage depends on the people you are working with. (Now, where I work , I use fortran, because everybody knows fortran. Which is not the case with C or C++).

This week-end, If I get some time, I will be doing tests again. And send you the codes and the results.

Regards.

John,

I don't think that VB6 is an order of magnitude slower than Fortran or C when it comes to number crunching. Although I increased the speed of my inviscid flow solver by a factor of 6 when I converted from VB6 to assembly, the actual speedup from the 'optimized' VB code to the 'optimized' assembly code was only a factor of 4. There were some inefficiencies in the original VB code which I did not notice until I started programming in assembly.

Also, on other 'number crunching' routines for which I did a VB6 versus Assembler comparison, I was not able to get things faster than a factor of 4. I would assume that my assembly code, which makes full use of the math coprocessor (utilizing all eight floating point registers for intermediate results) is still faster than your best compiled Fortran or C code.

Another thing about VB that you may not know: You can call any Windows API function from VB. You just have to know its name, the parameters which are passed, declare it, and you can call it like any other subroutine. Daniel Appleman wrote a book "Visual Basic - Programmer's Guide to the Win32 API". I only have the old version from 1996, but I am still using it like a bible. That book lists about every API function and is over 1500 pages.

I think you would be pleasantly surprised if you gave VB (version 6 that is) a shot. Although it has its drawbacks, I think it is the "fastest" and easiest language for application development.

Axel

(1). I have used VB since 91, but I am not using it anymore. It's great for business and web applications. (2). Number crunching using VB?, you are out of your mind. But to do prototyping ,it's all right. (3). Using assembly language? Not the long term solution.

That was the point I was trying to make: VB has gotten a lot better over the years when it comes to number crunching. I have only used it since 93 and have seen tremendous improvement with Version 6, which allows for native code compilation with several speed optimization options.

I have never done a side by side comparison myself, but I have talked to a developer who uses VB and VC++, and he told me that on math intensive routines VC++ was 'only' about twice as fast as VB.

(1). In old days, Byte magazine used to publish some simple integer and floating point test cases and the speed rating of various PC's. People were interested in the speed because PC was relatively slow in those days. (2). For a while, MS and Borland were competing against each other in terms of the compiler speed. These were golden days, when there were many hardware and software companies trying to improve the speed of computing. (3). With today's environment, the competition is almost gone. The general trend is the software is getting extremely large and slow. The hardware is controlled by one or at most two companies, so they control your speed. (4). Anyway, speed alone was never the only factor in selecting a programming language. There is a different trend though, on multi-tier network computing, people are using "COM" approach, where "interfaces" are used to talk to "binary-executables" written in "different languages". In that case, you are free to use any language to write the code, as long as you follow the interface specifications. (interfaces are methods or functions like IcomputeAplusB()...) But then the speed will be determined by the network speed. (5). Well, that's what they called "enterprise-computing". (6). My suggestion is: split MS into several language development groups, then you will see faster and smaller compilers every year. Otherwise, if the system program is written in c-language, then I guess Fortran is likely written in c.

(1). That's very encouraging. (2). From business point of view, I don't think they are going to improve it to match the speed of VC++, even if it's possible. (3). Based on my experience, VB is much easier to use than VC++.