Fortran vs C++ for scientific computing
Kobe
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?
Thanks very much for your time and your contributions.
Best regards,
Kobe
glen herrmannsfeldt
> 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>
> Fortran vs C++ for scientific computing?
Personally, I prefer Java over C++ as an object oriented C-like
language, but beside that...
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.
-- glen
Erik Edelmann
> Hi,
>
> 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* ?
I have never made any speed comparisons between C++ and Fortran myself, so
I can't comment on the speed comparison. Personally, I prefer Fortran
(Fortran 95, to be precise) because I feel it's easier to use. I tend to
produce fewer bugs in Fortran than in C/C++.
> 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?
If you are going to write lots of scientific codes, learning Fortran is
probably not a bad idea, but why Fortran 77 instead of Fortran 95?
Erik
beli...@aol.com
<snip>
> If you are going to write lots of scientific codes, learning Fortran is
> probably not a bad idea, but why Fortran 77 instead of Fortran 95?
I think most public domain Fortran code is still in the style of
Fortran 77 or Fortran IV, and it is good to know enough "old-school"
Fortran to use it. Arguably the most important resource for Fortranners
is www.netlib.org, and I doubt that even 10% of the Fortran code there
uses features introduced in Fortran 90 or 95. Even if the OP writes new
code in Fortran 95 (which I also prefer to F77), he may want to call
F77 codes.
Brooks Moses
> 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.).
You are reading far too much into too little data. That paper shows
that, on one or two specific problems and on one specific set of
compilers, C++ with the Blitz++ library performs better than Fortran
without a specialized math library at all. There is nowhere near enough
data to say whether or not this is generally true; moreover, it says
nothing at all about what the performance of Fortran would be if one
used a comparable math library.
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.)
> 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?
What is currently clear is that both languages are very good for
scientific computing and in common use, yes. As is C.
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 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?
Do not learn Fortran 77; it's obsolete, and a waste of your time. Learn
Fortran 95 instead. (The difference between the two is approximately
the same as the level of difference between C and C++, except that there
are good reasons one would use C instead of C++.)
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 "bmoses-nospam" address is valid; no unmunging needed.
Erik Edelmann
I agree that knowing about "old-school" Fortran is useful, but I would
still start with (a modern subset of) F95, and learn about common blocks,
entry, computed goto and such things later. The primarly reason why I
asked, however, was that there is a common misconception that F95 is slow,
and I thought that the OP might have that misconception too (he was
appearantly interrested in speed).
Erik
Joe Krahn
have used arguments of speed, but these are no longer valid. The main
slow-down in C comes from argument aliasing, but there are now standard
specs to avoid this problem, but not all compilers support it yet.
Another (small?) advantage was the simplicity of Fortran, but that is
not true for Fortran95.
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.
Joe Krahn
max
"Joe Krahn" <kr...@niehs.nih.gov> wrote in message
news:GFFTf.119$9r...@mencken.net.nih.gov...
> Kobe wrote:
> > Hi,
> >
> > 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.).
There were tales of the KAI compiler used taking two days to compile the
benchmark code. I'm not sure where I came across that, other than in some
trhead on the pitfalls of benchmarking - the KAI compilers were supposed to
produce the best code possible from that generation of compilers, but
necessarily the best code for routine edit/compile usage.
Ben Hetland
> Another (small?) advantage was the simplicity of Fortran, but that is
> not true for Fortran95.
Probably Fortran95/90 can be regarded a different language than
Fortran77, as they are about as different as C++ and C are, if not more.
> The main difference is that C++ must be extended to allow scientific
> programming, primarily matrix classes.
Hmm... They both need to be extended for many applications. But maybe
the Fortran "community" has been somewhat more successful in sharing and
expanding on a common set of libraries; making them often more easily
available (if not even boundled with the compiler).
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.
> There are a lot of different
> matrix implementations, so C++ code is much less portable.
I find this assertion doesn't at all fit with my experience. The first
time I was "exposed" to Fortran I guess was around 1991, but I've been
more or less "exposed" to it ever since. I never learned it formally,
and for many years I tried to avoid it as much as I could because I
found it ugly, primitive, and extremely limiting. But perhaps the main
motivation to avoid it has been that by being proficient in that
language, the chances were just too high that I would end up being the
one maintaining an old, large, undocumented, and completely unstructured
code base with no subroutine parameters and a lot of COMMON blocks. ;-)
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.
> Also, matrix class syntax gets rather cryptic looking.
This probably depends on who's reading it. To me (coming from C++ and C)
many of the Fortran constructs look cryptic. There are a couple of
interesting features that would be cool to have available in C++.
> 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.
True, yet C interoperability has been more or less everyday practice for
me in all Fortran code I've worked with. There seems to be a way to do
it on every platform, but every port is different and generally the
(minor) differences are just annoying.
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...
> 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.
It is especially interesting to hear the "fortran promoter" arguing
about how much faster the same algorithm is if compiled with the Fortran
compiler, and when you look at the actual implementation of the
compilers, you can see that the Fortran runtime library actually is
built atop the C runtime, so it's often an _extra_ layer of routines to
go through before the real library function is performed... How can that
possibly be faster?
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...
> 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.
Most of the code for this "math/scientific" programming I've seen, can
more or less be copied verbatim between the two languages, or with only
minor syntactical changes. (After all, remember that C inherited a lot
from Fortran IV/66, and C++ a lot from C, and now F2003 is maybe taking
back a few ideas from C++...)
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.)
--
-+-Ben-+-
Joe Krahn
> Joe Krahn wrote:
>
>>Another (small?) advantage was the simplicity of Fortran, but that is
>>not true for Fortran95.
>
>
> Probably Fortran95/90 can be regarded a different language than
> Fortran77, as they are about as different as C++ and C are, if not more.
>
>
>
>>The main difference is that C++ must be extended to allow scientific
>>programming, primarily matrix classes.
>
>
> Hmm... They both need to be extended for many applications. But maybe
> the Fortran "community" has been somewhat more successful in sharing and
> expanding on a common set of libraries; making them often more easily
> available (if not even boundled with the compiler).
representations. They are part of the language in Fortran, so the basic
math which is the center of scientific computing is portable. That is
the part that needs to be portable.
>
> 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.
I would not consider C as being very extensible; certainly less
extensible than Fortran95. Fortran95 is mainly about the concept of
extensibility, but not as extensible as C++. I think Fortran95 and
beyond are more about making things extensible, but with an attempt to
avoid being so extensible that it can be extended to something that no
longer seems like the same language.
What I mean is not that Fortran code is more portable among compilers,
but that mathematic code written in Fortran is more portable among
different people's programs.
It is true that Fortran compilers have too many extensions, which
interferes with portability, and which is why they should be avoided.
The thing about C++ is that looking at different people's source code
implemented with different class objects can almost look like different
languages. That is because C++ has a huge amount of flexibility. That is
good for a computer-scientist who is comfortable with a "large toolbox",
but is a big pain for people whose research is mathematical and not
based on computer science.
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'm not really a "Fortran promoter". In fact, I had sort of given up on
Fortran in favor of C++, due to the need for non-portable platform
dependent hacks/extensions to get certain tasks done. The problem is
when non-computer-scientists ask me what is the "right" way to do
matrices in C++. Oh, you need a matrix library. Which one? It depends on
what you are doing, and the "right" choice might change over time. But
which one is the "Standard" matrix library. STL I guess, but it's
probably not the best choice. This kind of stuff is just part of
programming to computer scientists, but a huge turn-off to everyone else.
>
>
>
>>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.
>
>
> Most of the code for this "math/scientific" programming I've seen, can
> more or less be copied verbatim between the two languages, or with only
> minor syntactical changes. (After all, remember that C inherited a lot
> from Fortran IV/66, and C++ a lot from C, and now F2003 is maybe taking
> back a few ideas from C++...)
>
> 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!
Yes, there is a lot of really bad Fortran code. It incorrectly
contributes to the general opinion that Fortran is an archaic language
that computer scientists should avoid.
>
> 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.)
>
Yes, another huge contribution to the wealth of bad code is that many
(most) Fortran programmers learn Fortran from the person next to them
combined with the availability of a huge amount of really bad source
code and non-portable compiler extensions. Modern Fortran could be a lot
better if computer scientists still used it as a tool rather than just a
bunch of old code to maintain.
F2003 features could make Fortran more computer-science friendly, but it
has come almost too late, after most of the computer-science community
had bailed out.
Joe
Richard E Maine
tend to participate much in language-vs-language debates (even civil
ones, as this has been so far). Do realize that any debate on this
subject will inherently involve only a subset of the people here, so
don't take much of anything that you here as necessarily agreed to by
the group as a whole. For exaqmple, I saw lots of things that I probably
disagree with, but I'm just not going to debate them. I'm not even going
to list them, because that would just invite debate. No, my silence does
not constitute agreement. Just a few tidbits I'll comment on.
Ben Hetland <ben.a....@sintef.no> wrote:
> 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.
This seems too overgeneralized - so much so that I have trouble telling
what you are talking about in concrete terms. Frankly, mostly I think it
is just false. In the large majority of cases where someone comes up
with a new idea for doing something, it is not done as a language
extension - in any of the above languages. I know of no such difference
in principle, certainly between Fortran and C. Now C++ is perhaps a bit
different on this, but you seem to be making a distintion between
Fortran and C - a distinction that I don't think exists.
> True, yet C interoperability has been more or less everyday practice for
> me in all Fortran code I've worked with. There seems to be a way to do
> it on every platform, but every port is different..
Absolutely. That was *EXACTLY* the point of standardizing it, and it is
hard to find a more appropriate kind of thing for standardization. When
"everybody" has the basic functionality, but the details of the spelling
differ - that's the kind of situation that just screams for
standardization. Early in the f2003 development process, I listed C
interop area as what I thought was the most important new thing in
f2003. I thought it was the one area so critical that a new standard
should not be put out without it - even if that meant delaying the
standard. I still think that call was good, and I've seen what I
consider to be supporting evidence.
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.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
beli...@aol.com
<snip>
> It is true that Fortran compilers have too many extensions, which
> interferes with portability, and which is why they should be avoided.
Fortran compilers introduced extensions to meet needs that were not met
by the language, for example command line arguments. Because of user
requests, g95, a relatively new compiler, does include many extensions
from other compilers, especially Unix-based ones. Doing so has
INCREASED portability of many codes, because they now run on any
platform where G95 is available (which is in theory anywhere that GCC
is available). The same is probably true of gfortran, but I know less
about it.
I think we would agree that a programmer improves portability by
avoiding extensions, whenever possible, in new code.
Ben Hetland
> I'm ignoring most of ths thread (and even most of this post). I don't
> tend to participate much in language-vs-language debates (even civil
> ones, as this has been so far).
I surely hope it doesn't turn into one of those wars of "why my language
is better that your language" at least! I hesitated before my posting
myself, but I think it's more important that we share experiences rather
than fighting on mere conviction... Disagreement is generally a Good
Thing[tm], in my view, because it enables us to validate our own
(preliminary) conclusions, possibly achieving something better.
> Do realize that any debate on this
> subject will inherently involve only a subset of the people here,
Such are most subjects! That's what threading is for... :-)
> that would just invite debate. No, my silence does
> not constitute agreement. Just a few tidbits I'll comment on.
Yes, but your "tidbits" are well appreciated, by me at least. In fact I
mostly agree with your comments, as they are well founded and just fill
in and elaborate on many of the things that maybe I didn't manage to
explain well enough. (English is not my native language...)
> Ben Hetland <ben.a....@sintef.no> wrote:
>
>> 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.
>
> This seems too overgeneralized - so much so that I have trouble telling
> what you are talking about in concrete terms. Frankly, mostly I think it
> is just false. In the large majority of cases where someone comes up
> with a new idea for doing something, it is not done as a language
> extension - in any of the above languages. I know of no such difference
> in principle, certainly between Fortran and C. Now C++ is perhaps a bit
> different on this, but you seem to be making a distintion between
> Fortran and C - a distinction that I don't think exists.
Yes, my wording was perhaps not getting my point through well enough. I
will try to make it more concrete.
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.)
> Early in the f2003 development process, I listed C
> interop area as what I thought was the most important new thing in
> f2003. I thought it was the one area so critical that a new standard
> should not be put out without it - even if that meant delaying the
> standard. I still think that call was good, and I've seen what I
> consider to be supporting evidence.
Oh yes! I cannot agree more on that.
Thank you for your effort in that direction, Richard!
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...
> 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.
Yes, they've all had to relate to this real-life challenge for a long
time, so lucky for many of us it is that they've at least provided us
with a way to do it for years now. :-)
> 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.
Just for the record: No, I didn't intend to suggest that is _isn't_ a
big deal. Sorry if it seemed like that. On the contrary, I offered my
"examples" more as a strong indication that this is an important area!
It hasn't been a show-stopper in my case, but there has always been a
period of great hazzle after each compiler-switch...
--
-+-Ben-+-
Ben Hetland
> My point is that C++ has to be extended just to get useful matrix
> representations.
Yup, you can say that. C++ in fact has to be extended just to do about
anything. Even printing a line of text... (Pick a library!)
> They are part of the language in Fortran, so the basic
> math which is the center of scientific computing is portable.
> That is the part that needs to be portable.
So here's perhaps where my knowledge of "practical Fortran" is limited.
I know you can operate very easily of arrays in F90, but I didn't know
that an expression like for instance A*B for two two-dimensional arrays
A and B really corresponded to a matrix multiplication. Please enlighten me!
Yes, this would definitely be unlike for instance the standard
valarray<> in STL for instance.
>>> There are a lot of different
>>> matrix implementations, so C++ code is much less portable.
But even with many such implementations, each of these are just as
portable as any other C++ code. So it boils down to licensing and policy
of the vendor if it's a commercial library.
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.
> The thing about C++ is that looking at different people's source code
> implemented with different class objects can almost look like different
> languages. That is because C++ has a huge amount of flexibility. That is
> good for a computer-scientist who is comfortable with a "large toolbox",
> but is a big pain for people whose research is mathematical and not
> based on computer science.
Yes, that fits my experience. If you're not focused on a "large
toolbox", you will appreciate _familiarity_ of the language every time
you need it. In fact you want it to simply represent as closely as
possibly your own way of expressing the ideas, which would be the
mathematical formulas in that specific case.
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.
> 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.
Yes, but the feeling is probably a different one for each of us. To me
personally, the C++ is the automatic one (doing things behind the scenes
for me, but I know what that is all about, like gear shifting). The C is
the manual alternative; here, What You Do Is All You Get. Gear shift is
explicit (manual). Fortran is like the old rusty car with a manual; it
occasionally stops and doesn't bring me where I wanna go. But that is
_for_me_. It so happens that I have another old rusty car that I love,
because I know all its ins and outs through years of experience and
getting familiar with it.
>>> 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.
Yes, but to me F2003 doesn't really exist yet! I need to see a real
compiler for it first, otherwise I cannot use it...
> matrices in C++. Oh, you need a matrix library. Which one? It depends on
> what you are doing, and the "right" choice might change over time. But
> which one is the "Standard" matrix library. STL I guess, but it's
> probably not the best choice. This kind of stuff is just part of
> programming to computer scientists, but a huge turn-off to everyone else.
Yes, you're probably right.
The "ideal" situation, as I see it, is rather to have the ability to
have different parts programmed in different languages. It could be due
to familiarity to the language for the one implementing a part, or it
could be due to the fact that different languages tend to support
expressing certain ideas better than others.
> Yes, another huge contribution to the wealth of bad code is that many
> (most) Fortran programmers learn Fortran from the person next to them
> combined with the availability of a huge amount of really bad source
> code and non-portable compiler extensions. Modern Fortran could be a lot
> better if computer scientists still used it as a tool rather than just a
> bunch of old code to maintain.
Yes, but they ("we") won't use it unless we see a specific advantage to
it. The language needs to provide us with something that warrants the
effort of learning it, and triggers interest into programming paradigmas
perhaps.
Fortran is not about that. Never has been. Fortran is the pragmatic
solution to the pragmatic implementer's life, i.e. the scientist.
> F2003 features could make Fortran more computer-science friendly, but it
> has come almost too late, after most of the computer-science community
> had bailed out.
I predict that the switch to F2003 will occur eventually as compilers
become available. But the reason will primarily be to increase (future)
portability and C-interoperability of legacy code. The switch will
probably even be driven by the "computer scientist", because these are
things that they are often faced with. Most "scientists" probably won't
care... unfortunately...
--
-+-Ben-+-
Richard E Maine
> Richard E Maine wrote:
> (English is not my native language...)
You do quite well in it - sufficiently so that it doesn't show.... and
better than many who do have it as a native language. :-(
> C doesn't even
> include I/O as a fundamental language feature, though it is part of a
> standard library.
> Now compare that to Fortran. There's both a WRITE and a PRINT for
> instance, and their syntax is slightly different.
Some of us - or at least one of us anyway - regard PRINT as an
obsolescent special-case of WRITE, but that's just a personal judgement,
and also wanders a bit off-topic.
> 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...
Hmm. Of course you can always do the function library approach in
Fortran. It almost sounds to me as though you are saying that Fortran
folk expect better integration, which is why it is harder to do in
Fortran - because while the typical C approach would work fine, that
wouldn't generally be accepted as good enough in Fortran. But I realize
that's not really quite what you said....and also tilts too close to
turning into a language war, so I won't really go there. I think it
would be an unfair comparison anyway, because...
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.
beli...@aol.com
Ben Hetland wrote:
<snip>
> So here's perhaps where my knowledge of "practical Fortran" is limited.
> I know you can operate very easily of arrays in F90, but I didn't know
> that an expression like for instance A*B for two two-dimensional arrays
> A and B really corresponded to a matrix multiplication. Please enlighten me!
A*B performs element-wise multiplication, and matmul(A,B) does matrix
multiplication. One can define operators so that A .x. B performs
matrix multiplication.
Joe Krahn
> Joe Krahn wrote:
>>>>There are a lot of different
>>>>matrix implementations, so C++ code is much less portable.
>
>
> But even with many such implementations, each of these are just as
> portable as any other C++ code. So it boils down to licensing and policy
> of the vendor if it's a commercial library.
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.
Joe
Ben Hetland
> Hmm. Of course you can always do the function library approach in
> Fortran. It almost sounds to me as though you are saying that Fortran
> folk expect better integration, which is why it is harder to do in
> Fortran - because while the typical C approach would work fine, that
> wouldn't generally be accepted as good enough in Fortran.
Hmm... You might have a good point there, indeed!
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...
--
-+-Ben-+-
Ben Hetland
> 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.
Yes, that's my experience too.
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.)
> 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.
I second that! It's also what often happens (ref. above), even if not
solved exactly in an ideal way.
--
-+-Ben-+-
Les
"Ben Hetland" <ben.a....@sintef.no> wrote in message
news:dvr616$rp7$1...@orkan.itea.ntnu.no...
<snip>
> 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?
>
Ah, alas we enter the realm of "if only".
50+ years ago if only we had had Unicode as the character set, with all of
those lovely symbols (pi, integral, sigma etc), and lots of cheap computer
memory and disk space, then FORmula TRANslation programs would have been
written using those symbols just like writing it down on paper.
I blame the computer manufacturers for not thinking far enough ahead.
:-)
Les
Jim
"Kobe" <kob...@email.it> wrote in message
news:X8ETf.41920$PR2.7...@twister2.libero.it...
> Hi,
>
> I was surfing the web looking for comparisons about Fortran vs. C++ for
> scientific computing.
>
writer wanted them to prove.
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
>
Dr Ivan D. Reid
wrote in <X8ETf.41920$PR2.7...@twister2.libero.it>:
> 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?
You may or may not knoew it, but that's a good way to troll up
a long discussion here, or a flame-war if cross-posted to other C-derived
groups...
> What languages importan scientific organizations (e.g. NASA, CERN) use
> for their scientific code?
At CERN I have to use C++ for "public" programming, tho' I still
do some quick and dirty personal data-crunching in g77[1] when awk is not
flexible/numaerate enough. OTOH, I've just heard last week from an old
TRIUMF colleague in DESY (IIRC) who tells me that C++ is frowned on there.
> 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++);
The consensus seems to be, learn F95, especially now gfortran and
g95 are mature enough for most purposes (the corner cases may still
be problematic in various situations). F77 is a proper subset of F95.
> - 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.]
Yes, but you have to remember that there are certain requirements
of the language that are easily overlooked to your detriment (esp. w.r.t.
aliasing in sub-program arguments). As someone once said, if you lie to
the compiler, it's gonna get you!
[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.
--
Ivan Reid, Electronic & Computer Engineering, ___ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".
beli...@aol.com
> On Mon, 20 Mar 2006 20:21:11 GMT, Kobe <kob...@email.it>
> wrote in <X8ETf.41920$PR2.7...@twister2.libero.it>:
<snip>
> The consensus seems to be, learn F95, especially now gfortran and
> g95 are mature enough for most purposes (the corner cases may still
> be problematic in various situations).
For me, g95 is mature enough for production use and gfortran is not,
yet. Gfortran *is* compiling more of my codes than it used to, using
the 28 Feb 2006 Windows version. If you throw a large Fortran 95 code
at gfortran that is not part of its test suite, hitting a compiler bug
is not unlikely. OTOH, I doubt there are many F95 codes that gfortran
will compile and g95 will not.
Of course, programmers' experiences will differ. Using gfortran as
one's primary Fortran 95 compiler, one may be able to write a large
code while avoiding its gaps.
Bart Vandewoestyne
>
> 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.
While you mention this... I am silently (it's a very vague idea)
thinking of writing out a proposal for a master's thesis subject related to
this issue. Could this be an interesting subject for a
master's thesis for a computer-science student? The comparison
of F95 vs. C++ for scientific computing?
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
--
"Share what you know. Learn what you don't."
Dan Nagle
Bart Vandewoestyne wrote:
<snip>
> While you mention this... I am silently (it's a very vague idea)
> thinking of writing out a proposal for a master's thesis subject related to
> this issue. Could this be an interesting subject for a
> master's thesis for a computer-science student? The comparison
> of F95 vs. C++ for scientific computing?
>
> 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'...
These days, I would discuss Fortran 2003 versus C++ 2003, assuming
you can find compilers for comparison. NAG is very close to f03,
I don't know of any C++03 compilers (but I'm not tracking them).
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
Greg Lindahl
Bart Vandewoestyne <MyFirstName...@telenet.be> wrote:
>While you mention this... I am silently (it's a very vague idea)
>thinking of writing out a proposal for a master's thesis subject related to
>this issue. Could this be an interesting subject for a
>master's thesis for a computer-science student? The comparison
>of F95 vs. C++ for scientific computing?
Yes, but it's extremely hard to do well. If you implement the same
algorithms in each language, the experience of the implementer or the
choice of approach may change the results dramatically. You'd also
have to do a wide variety of applications. There are plenty of
examples of inter-language comparisons that get all 3 of these
elements wrong.
-- g
Paul Van Delst
> On 2006-03-23, Dr Ivan D. Reid <Ivan...@brunel.ac.uk> wrote:
>
>>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.
>
>
> While you mention this... I am silently (it's a very vague idea)
> thinking of writing out a proposal for a master's thesis subject related to
> this issue. Could this be an interesting subject for a
> master's thesis for a computer-science student? The comparison
> of F95 vs. C++ for scientific computing?
I wouldn't find it interesting myself - to do, or to read about. Expanding on Greg
Lindahl's posted comments, how will you objectively measure the skill of the programmer(s)
in implementing the same "idea" in either language? I used the word "idea" since it's not
clear to me that even using the same algorithm is a fair test.
The analogy I use for this sort of thing is one of regular old spoken languages: e.g. the
comparison of English vs Spanish for scientific communication. Which is better?
cheers,
paulv
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
Gib Bogle
I agree.
Michael Prager
This is a very general question in that "better" must be
carefully defined in any comparison. In general, there are many
possible definitions, and results depend heavily on the
definition chosen.
This issue comes up again and again in comparing programming
languages, wines, automobiles, stereo systems, cameras,
prospective mates, ....
In your proposed comparison, many would say that the salient
issues have nothing to do with speed, but rather programmer
productivity, ease of maintaining code, ease of porting, and the
probability of introducing subtle bugs in each language. Those
are all hard to measure without bias. The problems in measuring
even speed differences in general terms have been discussed here
many times, and are not trivial.
We haven't yet mentioned that everyone thinks differently (or
"different" as Apple would have it), and that that will
influence some of the other factors. More objectively, everyone
is trying to solve a different problem, and even within the
realm of scientific computing, the specific problem and
algorithm chosen have huge influences on speed and ease of
programming.
So NO, I don't think it's a good topic for a master's thesis,
but thanks for asking!
--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.
John Harper
Bart Vandewoestyne <MyFirstName...@telenet.be> wrote:
>
>thinking of writing out a proposal for a master's thesis subject related to
>this issue. Could this be an interesting subject for a
>master's thesis for a computer-science student? The comparison
>of F95 vs. C++ for scientific computing?
Having come into this game via numerical analysis and seen how
uninterested in that subject most computer scientists seem to be, I
feel that computer science should be defined as the study of everything
you can do in a computer except floating-point arithmetic:-) Hence,
while I would like to see the result of such a thesis, I suspect it
would be more interesting for engineers, physical scientists and
applied mathematicians than computer scientists.
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
Brooks Moses
> While you mention this... I am silently (it's a very vague idea)
> thinking of writing out a proposal for a master's thesis subject related to
> this issue. Could this be an interesting subject for a
> master's thesis for a computer-science student? The comparison
> of F95 vs. C++ for scientific computing?
>
> 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'...
I think it would be a very interesting problem.
However, I do not think it would be interesting if approached by a
process of time-based benchmarking.
There is, fundamentally, an upper limit to how good any compiler of any
language can be on a given algorithm. There is also a fair amount of
statistical noise involved in benchmark results, such that any given
benchmark is not precisely representative of the overall compiler
quality. I would argue that, in most cases, the noise level is
substantially larger than the difference between the real data and the
upper possible limit, and thus that statistical comparisons will find no
statistically-significant differences.
Further, it can be difficult to benchmark compilers separately from
libraries; see my earlier post in this thread for contention that the
originally-cited paper is benchmarking the Boost++ library moreso than
the C++ language.
So, how can it be an interesting problem? Well, don't use time-based
benchmarking; use something else, that depends on the language.
Specifically, do hand theoretical analysis to show whether there are
limitations inherent in the language that prevent compilers from being
able to do possible optimizations. And then demonstrate these on live
code with live compilers using assembly-language compilation dumps.
One commonly-cited example of this is aliasing of variables in C/C++; in
some cases, the only way for a programmer to tell the compiler that two
independent variables are in fact independent is to use very recent
language features (which, I gather, are not supported in all compilers).
In Fortran, this is trivial; if they are dependent and the compiler
hasn't been explicitly told they are, it's a bug in the program.
I suspect that there are a additional things of this sort, though there
are probably relatively few of them. You may be able to find something
in the lack of explicit "pass by value" and "pass by reference" syntax
in Fortran, for instance. (Or you may be able to show that there isn't
anything there, which is also signficant!) Also, the example of whether
or not the compiler can optimize out (a + b) - b, as discussed recently,
is another potential example.
If that doesn't show up enough interesting results (other than perhaps
that they're both nearly fully expressive, and thus nearly equivalent
insofar as theoretical maximum performance), then it may be worthwhile
to look at more esoteric things like multithreading and suchlike, and
compare how difficult it is to extend the language for that sort of thing.
At the end, it is probably worth writing some small assembly-code tests
that differ only in very controlled ways, and benchmarking those to see
if the differences that are found (e.g., optimization that can be done
assuming variables don't alias) are in fact significant.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
Greg Lindahl
Brooks Moses <bmoses...@cits1.stanford.edu> wrote:
>One commonly-cited example of this is aliasing of variables in C/C++; in
>some cases, the only way for a programmer to tell the compiler that two
>independent variables are in fact independent is to use very recent
>language features (which, I gather, are not supported in all compilers).
Or use whole program compilation, feedback compilation, and runtime
checks. There's a cannon that kills that fly, honest. So this really
_isn't_ an interesting topic, unless you want to produce another study
that ends up being laughable.
-- greg
DVG
beat decent Fortran numerical
procedure in performance.
All other details is a matter
of personal/organizational
preferences.
--
*It is easy to lie with statistics, but it's a lot easier to lie without
them.
Bart Vandewoestyne
>
> These days, I would discuss Fortran 2003 versus C++ 2003, assuming
> you can find compilers for comparison. NAG is very close to f03,
> I don't know of any C++03 compilers (but I'm not tracking them).
I'm also not really tracking the C++ development and
standardization... so I was wondering what you meant by
`C++ 2003'... After some googling, i finally arrived at
http://www.open-std.org/jtc1/sc22/wg21/ and more specifically
http://www.open-std.org/jtc1/sc22/wg21/docs/standards#14882
I assume by `C++ 2003' you mean the `ISO/IEC 14882:2003 Programming
Language C++' technical corrigendum to the original C++
standard, being `ISO/IEC 14882:1998', right?
Regards,
Kobe
> You may or may not knoew it, but that's a good way to troll up
> a long discussion here, or a flame-war if cross-posted to other C-derived
> groups...
It's absolutely *not* my intention to cause flame-wars, and I only
posted this request to Fortran newsgroup (and not cross-posted to C/C++
groups) to avoid such bad things.
I'm very glad that this thread has evolved in a very civil way, and I
sincerely thank all the posters who gave very interesting and elaborated
answers to my questions.
(For me, programming languages are *tools*; I think there's not the
"absolutely better" programming language, but there are better tools for
specific domains.)
Ciao
Dan Nagle
Bart Vandewoestyne wrote:
<snip>
> I assume by `C++ 2003' you mean the `ISO/IEC 14882:2003 Programming
> Language C++' technical corrigendum to the original C++
> standard, being `ISO/IEC 14882:1998', right?
The C++ standard published in 2004 is a corrections document
to the C++ standard finalized in 98. They had a lot of things
to specify further, since C++98 was the first standard
for a rather large language.
robin
>It is generally impossible to
>beat decent Fortran numerical
>procedure in performance.
It's easy in assembler language.
robin
>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.).
Well, not really. Some of the tests are invalid.
For example, take the Fortran subroutine relating to Figure 5.
This subroutine consists of three nested loops for handling 3-D arrays.
The actual operation required was matrix multiplication.
The control variables for all the loops, and consequently the
subscript references to the arrays, are all REAL.
There are 15 conversions from REAL to INTEGER in the innermost loop.
The author complains of register spillage. No wonder!
Then in the C++ version, vectors are used, with one loop and one subscript.
No wonder that the Fortran code ran slow.
>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?
>
>Thanks very much for your time and your contributions.
>Best regards,
>Kobe
Michael Metcalf
"robin" <rob...@bigpond.com> wrote in message
news:MwZUf.15486$dy4....@news-server.bigpond.net.au...
Regards,
Mike Metcalf
Rich Townsend
I wouldn't be so sure. Take, for instance, the Itanium architecture; I
think you would find it very difficult to write an assembly-language
program that could implement a sufficiently-complex algorithm faster
than Fortran. Modern-day processors are not easy to hand-code assembly
language for.
In other news: still no working F77 TRIM(), eh?
cheers,
Rich
Dmitry Gorbatovsky
Most of the contemporary Fortran translators
implies good deal of optimization.
Hardly if ever achievable by human on sufficient
amount of code.
Cheers
robin
On the contrary, it's easy to beat Fortran - or for that matter,
any HLL - with assembly language.
Dan Nagle
Can Robin please post an example where a non-trivial calculation
on a modern processor is easily coded in assembler which
has greater efficiency than the output of a highly optimizing compiler
by an amount great enough to justify the time and effort needed
to do so?
Rich Townsend
No, he can't. And, of course, still no working F77 implementation of
TRIM(). And still no code that causes a compiler crash. Etc etc.
cheers,
Rich