I was surfing the web looking for comparisons about Fortran vs. C++ for
scientific computing.

I found this:

<http://osl.iu.edu/~tveldhui/papers/DrDobbs2/drdobbs2.html>

and from the benchmarks of the above site, it seems that C++ with
Blitz++ library performs better than Fortran (e.g. lattice QCD
benchmark, etc.).

On the other side, I've been told that Fortran compilers are the top for
optimization of scientific code.

My question is: what the experts of this newsgroup honestly think about
Fortran vs C++ for scientific computing?

Are the two languages both very good for scientific computing? Is
Fortran better than C++, or vice-versa, and *why* ?
What languages importan scientific organizations (e.g. NASA, CERN) use
for their scientific code?

I was going to learn Fortran 77 because I've been told that:
- Fortran compilers give top performances when compiling scientific code
(better e.g. than C++);
- there are lots of Fortran scientific routines tested and widely used.
[I already know C++, even if I'm not a guru of this language.]

What do you think about these points, too?

Object oriented code tends to do a lot of object allocation and
deallocation, and for faster code you want to minimize that, especially
in the inner loop.

To me, more of the difference in speed is in coding style than
language used.

What _is_ generally true is that more effort put into code optimization
generally produces results if it's done well.  I suspect that
considerably more care was put into optimizing the Blitz++ code for the
case in question than was put into optimizing the Fortran code.  And, in
particular, some optimizations were applied to the C++ version that
could have been applied to the Fortran version and were not.  (For
instance, the last speedup mentioned, from encapsulating things so they
are stored nearby in memory, is perfectly possible in Fortran 77 and
I've definitely seen it done; it's just a little trickier to write.)

My impression is that all three languages are reasonably equivalent in
capability as far as conversing with the hardware; decent compilers for
any of them can generate machine code that is relatively close to
optimal.  The differences, in my opinion, are largely irrelevant -- if
they are relevant, you probably need to spend more effort optimizing.

The relevant question, in my opinion, is which language is best for
conversing with the _programmer_.  Which language is most convenient to
write in, which language expresses the concepts of the chosen algorithms
  in the clearest way, and which language leads to fewer bugs by the
programmer.

Needless to say, the answers for that question depend heavily on the
project in question, and are not always the same.

For the work that I'm doing right now, I have some programs in C++ and
some in Fortran 95.  Part of the project is an unstructured-mesh flow
solver with lots of layers of object classes; C++ is very useful for
writing that sort of algorithm in.  Part of the project is
structured-mesh array crunching; Fortran is a very convenient sort of
language for that type of algorithm.

Personally, I like the fact that Fortran is fairly verbose; it allows
one to do a lot of things that help the compiler detect errors and make
the code "self-documenting".  I like the fact that it has a very capable
array-processing functionality as part of the base language, so that I
don't have to worry about loading libraries in order to do what I
consider basic stuff.  I like the fact that Fortran doesn't need
pointers for dynamic array allocation or passing variables, which avoids
a lot of potential bugs.

On the other hand, I like the fact that C++ is very easily extensible
with polymorphism and object inheritance.  I like C++'s header mechanism
better than Fortran's mechanism for importing modules.  I like the fact
that C++ is concise and takes a minimum of typing.

You'll note that some of those are contradictory.  That's why I use
both; sometimes one matters more than the other, sometimes it's the
other way around.

I would suggest that you should learn Fortran because it's a different
and useful language, and having an understanding of how other languages
do things provides you with better mental tools.  My Fortran programs
improved tremendously when I learned C++, for instance.

As a bonus, yes there is a lot of Fortran code out there for scientific
computing, and it's useful to be able to use and understand it.

- Brooks

The main difference is that C++ must be extended to allow scientific
programming, primarily matrix classes. There are a lot of different
matrix implementations, so C++ code is much less portable. Also, matrix
class syntax gets rather cryptic looking.

The main arguments against Fortran are the lack of C interoperability,
object sub-classing, limited string handling abilities, and possibly
stream I/O. Fortunately, F2003 fixes all of these.

I think the best summary is that Fortran and C++ can produce a similar
quality compiled program, but optimized C++ code will be more complex
than the corresponding Fortran code. On the other hand, C++ has a lot
more general non-math resources. So, C++ is a good choice for computer
scientists who will do a lot of non-math programming, and Fortran is a
good choice for a mathematical/physical scientist.

There's also a different underlying principle, and that is that a main
principle of both C and C++ are that they are _supposed_ to be extended,
and the syntax is supportive in doing it. "Fortran-principles", on the
other hand, is more like if somebody comes up with a new idea of doing
something, it should (or even must) be included in the language itself.
A more pragmatic approach, some will say. Both principles have pros and
cons, of course.

But anyway, my point is that during these years, code has moved from
platform to platform, and from one compiler to another even on the same
platform. (Not the same code as I've switched employers!) This has
generally included both C, C++, and Fortran sources. But without
exception Fortran has always been the one that caused problems,
typically due to issues like poor availability of compilers (F77
somewhat good though), different compilers tend to detect different
errors, compiler extensions were almost always used and weren't
compatible, and available compilers have tended to be buggy compared to
C/C++ compilers.

C is almost never a problem, except perhaps in very platform-specific
code (which also is true for C++). C++ is generally good, but support
for the latest standard (and thus standard-compliant "correct" code) has
been rather poor, and that has especially been a pain with templates and
STL. The latter problem seems to be fading away now, luckily.

But has this been Fortran's fault? Probably not!

We have to look at which kind of people have "traditionally" been
producing this code. I cannot judge for others, but in my case it has
been mostly two kinds of people; the "scientist" with a lot of theory to
explore, or the "technical professional". By the latter I mean people
that have been educated primarily to a completely difference profession
than "computer science" at least, but for some sub-set of their tasks
they use Fortran as a tool. Often what they produce is a single source
file "thingy" around 1-2000 LOC. Maybe they've got a short introduction
course in Fortran during their education, or maybe they just learned it
later more or less on their own. The "scientist" category also learned
Fortran about the same way, it seems.

People with a "computer scientist" background, or similar, probably
never learned Fortran during their education at all. Some other
theoretical aspect of software development is likely to be more of
interest to them, and Fortran is not especially attractive to explore
many of those idioms. I guess I belong to this group, and that most of
us are still being exposed to Fortran more of practical necessecity than
anything else.

Common to all three groups, but for different motives, getting to
actually know the language one is using, is only of secondary interest
-- if at all. It should be a principle that one knows the language one
is using, but that isn't always the case, so instead it becomes the
specific compiler's rules that are the real constraints enforced, not
what the standard says! Hence, code becomes generally very non-portable.

The question now is of course how long it will take before F2003 is
really available, and one can expect it to also be available if one
chooses to switch platform. That sure took a long time with F95...

On the other hand, a Fortran compiler can safely make a lot of
assumptions about pointers, pointees, and variables etc. in the code,
that a corresponding C compiler cannot, and this can be an advantage
during optimization stages. It can probably even outweigh an extra level
of run-time libraries if that is being used...

And where C implementers often use "#include <math.h>" or the like, many
Fortran programmers tend to be less disciplined and inclined to define
things themselves instead, so we get a lot of statements to do "PI =
4*ATAN(1.0)" and "G = 9.81" etc. all over the place. Not the language's
fault, and not really a language difference, just bad habits!

It's also important that one actually uses the language one is
confortable with. So often I've recommended scientists to stick with
their Fortran rather than trying to learn C or C++. They will probably
not learn it well enough anyway, and shouldn't waste their time on
something that they will need only occasionally, and maybe don't share a
genuine interest in anyway, IMHO.

So why am I hanging around in this group, you may ask. The reason is
that I really want to learn more about the language I have to maintain
anyway, and its features. People here seem to be generally more
concerned about the language itself and its standard! After all, there
is an abundance of legacy code in Fortran, which has been maintained for
years, and probably will be for years to come. The more I learn, the
more surprices surface, and things that the "Old Boys" once taught me
about the properties of Fortran often end up being a completely wrong
assumption about the "standard". In fact it proves to be more about a
specific compiler implementation. (Implicit SAVE of local variables in
subroutines is a more recent example from the discussions here.)

It is true that Fortran compilers have too many extensions, which
interferes with portability, and which is why they should be avoided.

I suppose you could compare it to a manual versus automatic
transmission. An automatic is easy to use, but gives less control. Race
cars always have manual transmissions. Fortran is like the automatic
transmission: useful for people who are trying to get from point Q
(question) to point A (answer). C++ is the manual transmission: you have
more control and can do fancy maneuvers, but it takes more experience
and skill to drive.

I'll think you will find that

1. The "small" differences grow from the annoying category into major
obstacles as the size and distribution of the code grows. Start with a
trivial annoyance when porting one howm-grown code to a second platform.
Now make this code one of a few million lines, with pieces supported by
multiple people in different organizations. Require it to be supported
on a dozen or so platforms, with new ones added on occasion. Distribute
it to environments where the installers have no way to contact the
developers. In short, work on a large production project, instead of a
home-grown small one. You'll find those "annoyances" have grown to be
show-stoppers.

2. The issues are only small if you stick to the bare minimalist
approach to interoperation. The f2003 stuff extends interop into some
areas where it was not formerly reasonably portable.

Note that if you talk to actual vendors, you'll find that almost
universally, C interop is very high on their implementation priority
list. Several of them already implemented it. Some of them implemented
it before it was even finalized in the standard (and then resisted even
trivial changes on that basis - for example, I wanted to change the
spelling of BIND(C) to LANG(C) or LANGUAGE(C), but any possible merit to
that was irrelevant to vendors who had already implemented it and had
customers already using it). Why is it so high on their priority list?
Because when they survey their customers, it usually comes out very high
on their customer's priority lists. This sounds like pretty strong and
broad real-world evidence of something to me. It is broad enough
evidence to be more meaningful than any one person's individual
experience. I'd say that if your experience suggests that it isn't a big
deal (and I realize you didn't use those words, so that might not be an
accurate representation), but vendors and a large number of customers
are making a big deal of it, perhaps there is data there.

First, yours and also Joe Krahn's comment on this, seem to indicate that
we might be thinking of something different when we talk of an
"extension" to a language. I still don't see quite how you guys define
that, but I can try to clarify my "definition" at least.

By an "extension" to a programming language, I think of a new feature
that in some natural way (the more the better) tends to "blend into" the
existing features or language syntax. What is actual "natual" depends on
the language. In C, for instance, only a minimal set of primitives are
provided by the language itself, which includes a few basic data types,
operators, statement constructs, and some means of combining these into
new building blocks (basicly struct and functions). C doesn't even
include I/O as a fundamental language feature, though it is part of a
standard library. Subroutine and function calling in C takes the form of
_an_operator_ (the () operator) being applied to some data (a function
pointer).

Extending the language is done almost constantly (in my definition of
the term), as even the most elementary operations take the form of a
function call expression. In view of this, rolling your own I/O or
anything else doesn't really make the code to use it look fundamentally
different, so one can just view it as an extension to the way you would
have done a similar thing with the "standard library" anyway (except
exactly what you want is not necessarily available). The syntax is the
same; no new rules apply.

Standardisation in C is a lot about the functionality available in the
standard libraries, even if you don't have to use that library at all.
In fact, only a few things in the language's development has taken form
of extensions to the language itself.

Now compare that to Fortran. There's both a WRITE and a PRINT for
instance, and their syntax is slightly different. As far as I can see,
they do basicly more or less the same (yes, I now they are not 100% the
same). What if I want to make my own version of this, to print UTF-8
strings for instance, I'd have to use a different syntax -- a different
kind of statement probably -- like a CALL. To get this into the PRINT or
WRITE in Fortran, I guess you'd have to wait until the next language
standard...

Sure, it can be done in both languages, but IMHO in C in blends more
naturally into the existing mechanisms of the language. However, I also
see advantanges with preferring the CALL/PRINT syntax over the C.

Taking another example, all these nice array specifications that you can
do in Fortran 95 for instance, like "A(2:46)=0.0" or "WHERE..."; again
it's built into the languange using additional, convenient syntax. In C
or event C++, there's nothing directly like it! If you need that in C,
the most "natural" way for a C programmer to add it is probably not to
request a new set of syntax rules (or "language feature"), but rather it
would come as --you guessed-- a function library... Again, while both
languages can support it, the Fortran programmer has the advantages that
he's always got it there. He might have waited some years for it to come
his way, but now he's always got it right there at his disposal without
any extra effort on his side! The C programmer on the other hand,
doesn't have to wait for a new compiler, but he has the added burden of
finding (or implemented) the library.

As for C++ (although I guess you probably got my point anyway by now),
in that language a lot of the "extensibility" is focused around
overloaded functions/methods/operators, and extending classes. In C++
the general direction of extension is about making new _types_. Also a
lot spins around generic programming --algorithms for instance-- by
means of templates. Typically, gone is often the function call, now
reincarnated as operators and messaging (methods) instead. This acts as
syntactic sugar, and enables new types like matrices to blend naturally
into expressions resembling the mathematical ones. So it acts as an
extension of the vocabulary the programmer has at his or her disposal.
Some love it, while others hate it...

Here again, Fortran 95 has its niche. You can even extend the language
with your own entirely new operators if you like, something that C++
doesn't allow.

Anyway, I hope I don't start a language war with these example. Instead
what I want to achieve is a better understanding of each of the
languages on its own principles. "Different" doesn't necessarily mean
better or worse, and usually it is both at the same time. :-)

(Now I guess it's your call to enlighten me on what your idea of
extensibility is all about.)

Some day I hope that more languages learn from this, and continue adding
_standardized_ support for inter-language-operability. Not even C and
C++ are good enough here, IMHO. About three years ago I integrated a lot
of C code into a C++ program, and I was caught by surprise how difficult
that proved to be in practice. The 'extern "C"' of C++ was far from the
solution to all my challenges...

It hasn't been a show-stopper in my case, but there has always been a
period of great hazzle after each compiler-switch...

Yes, this would definitely be unlike for instance the standard
valarray<> in STL for instance.

However, your point is very valid for very advanced _pre-standard_ C++
implementation, because they often relied on compiler-specific behavior.
That has definitely been a problem.

Familiarity is probably better achieved through an established
"standard" of some sort, and not a language extension to fit your needs,
because it would tend to stay around longer.

Still, mosts of "my scientist co-workers" seem to still prefer
fixed-format Fortran77. Then they gradually sprinkle some F90 array
operations into there perhaps, because they've seen it somewhere and the
compiler allows it. It doesn't necessarily mean they know the difference
between F77 and F90. Wading into free-formatted F90 land is way too
scary, anyway. They simply loose familiarity, and cannot focus on their
algorithms or formulas.

Another thing I often see, is that _variable names_ are treated more
like mathematical symbols. They aren't the same concept really, but it
fits the mathematical similarity.

Fortran is not about that. Never has been. Fortran is the pragmatic
solution to the pragmatic implementer's life, i.e. the scientist.

Most add-on stuff is done as libraries in both languages. The huge
majority of it. That's exactly what I was thinking of when I said
something about them being similar. The huge base of existing add-on
libraries is often cited as one of Fortran's strengths. And the large
base of API's to things like operating systems is often cited as a
strength of C. I'm just not seeing as much of a contrast here as you
seem to in terms of how programmers add new features.

Fortran programers don't add new features by modifying language syntax
either. They might suggest syntax ideas (as many do here), but it is a
long road to get such ideas into the language. Applications don't tend
to be able to wait that long. For day-to-day work, a Fortran programer
adds stuff by writing libraries just as a C programmer does.

I'm not talking about code portability among compilers, but expression
portability among different people's programs. People who want to spend
time on the math and not the computer-science prefer to have a specific
syntax for a math expression. In C++, the same procedure can look quite
different with different matrix classes. That means spending more time
thinking about programming, which seems pretty normal if you are a
programmer. Mathematicians want to think more about the math; spending
time thinking about programming just takes away from their research.

In fact, a lot of scientists never want anything more than "throw away"
code. Just cobble something together that demonstrates a computational
method so you can publish a paper. So, in some ways, the choice between
Fortran95 and C++ depends if your goal is just to crunch numbers (using
Fortran as a massive programmable calculator), or whether you want to
write "Applications".

I think a good scientific application needs computer scientists working
on making the program work well, and mathematical/physical scientists
working on methods that give the right answers.

With a languange comes culture, and that is probably true for
programming languages as well as natural languages. (Or maybe it's the
other way round...) So one could guess that the "culture" in
Fortran-land is to demand comfort so you can be seated well while you're
working.

I C-land everyone is more like a do-it-yourself'er, and if you don't
fancy a particular library function, you roll your own. (Just be sure
not to tell too many about it. ;-) You don't mind reinventing the wheel
over and over again, just for the "fun" of reimplementing it... ;-)

That is a bit of over-generalizing, of course. For sometimes it puzzles
me why for example π seems not to have made it into the core Fortran
language yet* (as a "parameter PI" perhaps), or its intrinsics, and
"everyone" seems perfectly happy with writing 4*ATAN(1.0) over and over
again in every subroutine... Just gotten too used to it, perhaps?

Personally I think both "sides" have something to learn from each other.

*) or I'm just unaware of it...

Except often the pile of cobble is later shuffled over to the
programmers who are then expected to make a cobble street of it. (Are we
getting too metaphorical now?) They (the programmers) try to tidy up
some of it, adding IMPLICIT NONE and a few hundred declarations to make
it compile safely along with the rest of the stuff. They leave the bulk
of it though, because they don't understand the tricky formulas anyway.
Then they are destined to maintain it. At this point the code has become
the programmer's "property", because the scientist doesn't recognize it
as his own code any more.

Happens for more than Fortran, but Fortran is often the originator's
language of choice.

I'm trying to find a way to avoid this "transfer of ownership" occuring,
but I haven't come up with a practical solution to that yet. (Not one
that the scientist will not resist, that is.)

<snip>

It is also true that vendors can optimize their compilers for the common
benchmarks.

So, I tend to take all such pronouncements with a grain of salt, if not a
whole mountain of salt.
Jim

[1] The latest version of Scientific Linux CERN includes gcc 4 and thus
gfortran (F95); it's not deployed on the public machines yet though.  I'm
still looking for a niche where I can do a real F95 vs C++ test, but most
of our codes are far too complex.

I don't see any problems in guiding and assisting a student with his
F95 and C++ problems, but the main question I have is 'what scientific
problems am I going to let him solve so that the comparison is fair'...

Any suggestions are very welcome!

Best wishes,
Bart

--
Cheers!