I have a personal experiance with the comparison between fortran 90 and C/C++.

The same program, with the same algorithm, when implemented in both fortran 90 and C, the fortran ver ran "2.2" faster than the C ver

The result was a surprise since i expected the contrary

Why would you expect the contrary? Fortran has a much larger library of math functions, and a longer pedigree of people working to make those functions run as fast as possible. However, C/C++ has made a lot of strides, and I am somewhat surprised at the figure of 2.2 times faster. Did you use C or C++, and are you sure you compiled both codes with equivalent optimizations? What steps did you take to ensure that the comparison was as fair as possible?

For tightly written code with effective optimisers one might expect a 20-50% advantage in favour of Fortran because the Fortran optimiser is not required to handle aliasing of arrays whereas the C/C++ optimiser does.

The figure of 2.2 looks too big unless the Fortran and C/C++ compilers are from different suppliers in which case differences of this size either way are quite normal. If they are from the same supplier it would tend to suggest some of the code is not tightly written.

With modern microprocessors as soon as the arrays are large enough to overflow the cache performance plumets due to the time to access data from main memory. In these very common circumstances the in-cache performance of the chosen language is not particularly important.

First of all, you did refer to C or C++ as the same thing. So, I imagine that your C code corresponds to a C-TRAN type code, i.e. your fortran code rewritten with C systaxis. Of course efficiency can quite lower if a code is rewriting without considering the characteristic of the new language.

C++ can perform faster or similar to fortran 77 using metaprograming, templates, and so on, see for example

Boost Basic Linear Algebra http://www.boost.org/libs/numeric/ublas/doc/index.htm

Blitz++ Home Page oonumerics.org/blitz/

The Matrix Template Library osl.iu.edu/research/mtl/

In particular, you should take a look in the papers

"Will C++ be faster than Fortran?" Proceedings of the 1st International Scientific Computing in Object Oriented Parallel Environments (ISCOPE'97).

"Scientific Computing: C++ vs. Fortran," Dr. Dobb's Journal (November 1997). Focuses on optimizations for small linear algebra objects.

availables at oonumerics.org/blitz/

> C++ can perform faster or similar to fortran 77 using metaprograming,
: templates, and so on, see for example

For array based numerical work this statement is wrong. A knowledge of how compilers work or an appeal to less promotional and more reliable sources (e.g. the author of C++) would be recommended.

The features you mention are required to remove the large computational overhead of the language and allow the speed of C++ code to get close to that of Fortran but a difference due to array aliasing will still remain (and a few other less important factors for numerical code). If you look at the examples where C++ is faster than Fortran you will almost always see hand optimisation performed in C++ code that are not performed in the Fortran code. This is not a valid comparison of the speed difference between the two languages.

In order to address the aliasing problem C99 introduced a restrict annotation which, in theory, will allow array based numerical code in C99 to run at Fortran speeds (ignoring the faster Fortran function calls and a few other things not important to numerical code). C++ does not have this annotation.

C++ has a number of advantages relative to Fortran but the "native" speed of the language for numerical work is not one of them.

Did you remember to reverse any nested do/for loops? This is required for array accesses since C and FORTRAN store arrays internally in a different order; e.g. for the array A(i,j) the i loop will, in general, be the inner loop in FORTRAN while for C it should be j. This could explain the factor of 2.2 which appears a bit larger than I would expect (although if for example you are using the intel FORTRAN compiler and the GCC Compiler a large value may be expected - a fairer test would be to use the intel C++ compiler in this case).

>For array based numerical work this statement is wrong.

I have shown references where the performance of C++ is similar or faster than fortran 77 for array based numerics. Basic mathematics give that there are AT LEAST some cases where this is true, and so your comment is incorrect.

>A knowledge of how compilers work or an appeal to less >promotional and more reliable sources (e.g. the author of >C++) would be recommended.

I can recommend the article: Abstraction, libraries, and efficiency in C++ http://public.research.att.com/~bs/abstraction.pdf (by the author of C++)

>The features you mention are required to remove the large
:computational overhead of the language and allow the speed
f C++ code to get close to that of Fortran but a
:difference due to array aliasing will still remain (and a
:few other less important factors for numerical code). If
:you look at the examples where C++ is faster than Fortran
:you will almost always see hand optimisation performed in
:C++ code that are not performed in the Fortran code.

You are right, these features are essential for getting high performance but also reusability, design, scalability and so on. There are several performance evaluations, in particular if you can get better number for fortran respect C++ you can submit your evaluations. Some evaluations are respect BLAS, LAPACK which are optimized libraries. If you still have problem you can develop your code using C++ and calling for this libraries.

> This is not a valid comparison of the speed difference
: between the two languages.

Maybe not, but you was not so worry before when fortran was better. So, I think your definition of "a valid comparison" depends on the winner.

>In order to address the aliasing problem C99 introduced a
:restrict annotation which, in theory, will allow array
:based numerical code in C99 to run at Fortran speeds
ignoring the faster Fortran function calls and a few
ther things not important to numerical code). C++ does >not have this annotation.

The C99 is the 1999 ISO C standard, C is not C++. Although, you can use "restrict" in most compiler this is not in the c++ standard yet. Take some time to introduce changes into the stardards. You can see the some problem with the standards for fortran 2003 which included concepts availables from the 80s. However, you are limited because compilers are not implmenting this issues.

>C++ has a number of advantages relative to Fortran but
:the "native" speed of the language for numerical work is
:not one of them.

I consider that scientific computing is more than solve an equation. Scientific computing demands several areas: mathematics, numerics, software, ....

Nowdays, the size of the scientific codes project are in general important. Therefore, it is important to use the progress in the computing science for handling such projects. Using only a fortran compiler is not enough. If you really like fortran you can use in some part of your project for example calling BLAS, LAPACK, .... optimized libraries. Using high level languages for the main part of you system. Of course it is not free. Developing software in C++ requires to learn how to program in a new paradigm like object orientation and this take time, and after that you need learn about generic programing for getting better design and performance.

"if your only tool is a hammer, you tend to see every problem as a nail"

" Please do not misinterpret my appreciation of FORTRAN: if there had been a Nobel prize for computing science FORTRAN would have been an achievement worthy of it. But that appreciation should not engender the mistaken belief that FORTRAN is the last word in computing; on the contrary, it was one of the first words. It is just no longer adequate: since the twenty years of its existence, the computing scene has changed by several orders of magnitude. How could it still be adequate? We don't control Jumbo Jets by whip and spur! " E.W. Dijkstra

And you can use optimization etc. to make it faster. F77 is even faster than the F90.

Vino Dhiman

> I have shown references where the performance of C++ is similar or faster
: than fortran 77 for array based numerics.

But you have not looked at the code to find out why. If you do this, as I have done, you will find the C++ code has handwritten "compiler optimisations" and the Fortran code does not. If you add the same coding to Fortran the results will revert to normal.

> The C99 is the 1999 ISO C standard, C is not C++. Although, you can use
: "restrict" in most compiler this is not in the c++ standard yet. Take some
: time to introduce changes into the stardards.

At the time it was adopted by the C committee it was considered and rejected by the C++ committee. I take little interest in this sort of thing these days but I would not rely on it being adopted in standard C++ unless you have read something to the contrary in the last few years.

If you are unsure of what aliasing means for arrays here is a link with an example (researchers not understanding the differences between Fortran and C/C++ for numerical work is an old and annoying one for those that support numerical computation!):

http://www.hpcf.cam.ac.uk/C_rant.html

retrict is been adapted by several compilers, so there are some possibilities of including it in the next standard. Any way, you can use restrict if you want. Something similar is with fortran, people require more capabilities then the standard adapt the requirements.

>But you have not looked at the code to find out why. If you do this, as I have done, you will find the C++ code has handwritten "compiler optimisations" and the Fortran code does not. If you add the same coding to Fortran the results will revert to normal.

This is typical. I can use the same argument when people compare fortran, with other languages. Of course, things go wrong. It is important to note that compiler technologies are evolving a lot from the 70s. High level languages present more challenges for the compiler technology. Getting a high level of abstraction without affecting performance is a real challenge.

> If you are unsure of what aliasing means for arrays here is a link with an example (researchers not understanding the differences between Fortran and C/C++ for numerical work is an old and annoying one for those that support numerical computation!): http://www.hpcf.cam.ac.uk/C_rant.html

I consider that people understand the differences between C++ and fortran. In particular the limitations of fortran for scientific codes. For that reason, a lot of research is going on in developing better software paradigms for scientific computing, e.g.

Berti, G. (2000). Generic Software Components for Scientific Computing, PhD Dissertation, TU Cottbus.

Gerlach, J. (2002). Domain engineering and generic programming for parallel scientific computing, PhD Dissertation, TU Berlin.

Alexandrescu, A. (2001). Modern C++ Design: Generic Programming and Design Patterns Applied. Addison Wesley Professional.

I can also show a list of c++ applications in research and industry e.g.

http://acts.nersc.gov/pooma/ http://acts.nersc.gov/pete/ http://www.cerncourier.com/main/article/45/1/21

If you like fortran, it is o.k.. I consider that other languages like c++ are much better. Any way, I consider that if you develop your code in a high level language you should also use some routines from fortran. There are no reason for ignoring highly tunned libraries. Similarly, there are no reason for no using the best of each world.

In addition to all the usual pros and cons and general "my favourite language is better than yours" debate, step back a bit and think more generally.

Simple inflexible languages are always going to be easier to optimise than complex, flexible ones. QED.

> If you like fortran, it is o.k..

There is not much to like about Fortran but it is usually the appropriate language for numerical code. It is almost never the appropriate language for other types of code.

> I consider that other languages like c++ are much better.

Yes I think people reading your posts will have picked that up. The only problem was the claim that C++ was faster than Fortran for numerical code and I have tried to point out why this is false.

> Any way, I consider that if you develop your code in a high level language
: you should also use some routines from fortran.

Yes the combination of a high level language with Fortran is an effective one in research circles.

I used a compaq fortran compiler and a MicroSoft VC++6 compiler. Also I DID reshaped the matrices and the same program algorithm. The test case was to assemble the global system matrix for a 3600 element local matrices in sparse matrix format.

The Actual Times:

Fortran ~ 90 secs C ~ 210 secs

ratio~ 2.333

FORTRAN = FORmula TRANslation

Enough said....

>Yes I think people reading your posts will have picked that up. The only problem was the claim that C++ was faster than Fortran for numerical code and I have tried to point out why this is false.

Well, in my post I was trying to show that fortran is not a magical solution. There are several options and efficiency depends strongly on the programer. I dont think that you pointed out why fortran is better than other languages. In my respect your comments or arguments are mainly of teological ground more than scientifical ones.

Again, I consider that scientific computing demands the interoperability of several languanges. C++ and fortran between them. To be stucked to one technique or tools is never acceptable.

"You can measure a programmer's perspective by noting his attitude on the continuing vitality of FORTRAN." Alan Perlis

"FORTRAN, "the infantile disorder", by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use." Edsger W. Dijkstra (How do we tell truths that might hurt?)

>>> Well, in my post I was trying to show that fortran is not a magical solution. There are several options and efficiency depends strongly on the programer. I dont think that you pointed out why fortran is better than other languages. In my respect your comments or arguments are mainly of teological ground more than scientifical ones.

I think that Andy has exposed some valid arguments about why fortran has certain advantages over C in certain circumstances i.e. crounching number. The argument concerning the aliasing seems to be a receivable one, isn't it ?

In fact, it is your comments that seem "are mainly of teological ground more than scientifical ones"

1. C is not C++, is it difficult to get it ? "Through C to C++: A Complete Programming Course, Barry Holmes"

2. problems with alising: use restrict

3. is it alising your main bottle neck ? remember the rule 80-20.

3. problems with performance in C++, maybe some good references help:

How Not to Program in C++: 111 Broken Programs and 3 Working Ones, or Why Does 2+2=5986, Steve Oualline

Using the Stl: The C++ Standard Template Library, Robert Robson

Effective C++: 50 Specific Ways to Improve Your Programs and Design, Scott Meyers

More Effective C++: 35 New Ways to Improve Your Programs and Designs, Scott Meyers

C++ Templates: The Complete Guide, Nicolai M. Josuttis, Nicolai M. Josuttis, David Vandevoorde.

A First Course in Computational Physics and Object-Oriented Programming with C++, David Yevick

Parallel Scientific Computing in C++ and Mpi: A Seamless Approach to Parallel Algorithms, George Em Karniadakis, Robert M Kirby II

C++ and Object Oriented Numeric Computing for Scientists and Engineers, Daoqi Yang

Scientific and Engineering C++ : An Introduction with Advanced Techniques and Examples. John J. Barton, Lee R. Nackman

An Introduction to C++ and Numerical Methods, James M. Ortega

The C++ Programming Language, Bjarne Stroustrup

Introducing C++ for Scientists, Engineers and Mathematicians, Derek Capper

...

and so on, this is 2006, sorry it is time to change or at least to accept that something is chaging.

In this case you are not just comparing the speed of the two languages. By using different suppliers for your compilers you have introduced the relative performance of the two compilers as a factor (a quick scan of compiler benchmarks will show how large this can be for numerical code). Also, writing fast code in the two languages is a nontrivial exercise particularly for C++. There is every chance that both your codes are not as quick as they could be. For example, perhaps you are achieving 50% the speed of tight Fortran code and 33% the speed of tight C++ code.

I Agree with you!!

In an effort to end my contribution to this branch of the thread, perhaps I should point out that I have programmed in C++ for over 15 years and I am familiar with many of the references you have been throwing up. More importantly, I am also familiar with a range of other programming languages which allows me to put the advantages and disadvantages of C++ into perspective.