C++ too slow for scientific computation 
Author Message
 C++ too slow for scientific computation

Some timings of programs written in C, fortran and C++ have been
published in an article in the last "Computers in Physics" (Nov/Dec '94).

The results, in a nutshell, are that C++ times are much slower than
C on all platforms but the Cray C90. And C is uniformly 1.25-2x slower
than FORTRAN.

No mention is made of code size. However the hearsay is
that C++ executables are much larger than FORTRAN ones, which are them-
selves much larger than they need to be.

Speaking for myself, the chief reason I don't use C++ is that none of my
machines are big or fast enough even to _compile_ a simple program!
On the other hand, a very complete Forth runs adequately fast (without
optimization) on a small laptop, and I can prototype code, I daresay,
as fast as anyone using a fancy workstation with the entire panoply
of programming tools, and working in C or C++. If I choose to hand
code a few subroutines in assembler, the result runs as fast as FORTRAN.
Just some food for thought.
--
Julian V. Noble



Wed, 28 May 1997 06:28:42 GMT  
 C++ too slow for scientific computation

: Some timings of programs written in C, FORTRAN and C++ have been
: published in an article in the last "Computers in Physics" (Nov/Dec '94).

: The results, in a nutshell, are that C++ times are much slower than
: C on all platforms but the Cray C90. And C is uniformly 1.25-2x slower
: than FORTRAN.

        Of course, this all depends on the relative skills of the
programmer(s) in these languages.  I daresay that if I was forced to
code a project in fortran tomorrow, it would probably run pretty
slowly.  I'd probably spend a long time figuring out how to code up a
linked list, for example..

: Speaking for myself, the chief reason I don't use C++ is that none of my
: machines are big or fast enough even to _compile_ a simple program!

        What kind of machines are you running on?  Even a tiny PC
seems to compile C++ okay.

: On the other hand, a very complete Forth runs adequately fast (without
: optimization) on a small laptop, and I can prototype code, I daresay,
: as fast as anyone using a fancy workstation with the entire panoply
: of programming tools, and working in C or C++.

        Hmmm.. I dunno.  I'm guessing that you're writting pretty
simple programs here.  What happens when new entities are being
created in the program?  Suppose you need to stick information into a
B-tree?  Wanna insert a skip list for that extra speed?  Code up one
of these in C++( or get a library ) and it's yours forever; how will
you do that in fortran?  How will you define complex relationships
between entities?

        I'm just saying that "speed of prototyping code" is not merely
realted to compile time.  I can code a hash table in a few seconds( I
have a template ) in c++, possibly making my program much faster.  How
long will this take in FORTRAN?

--
------------------------------------------------------------------------------

| Laboratory for advanced computing      |      My employer barely KNOWS me. |
------------------------------------------------------------------------------
A conversation with godess:

"I am filled with fear and tormented with terrible visions of
pain. Everywhere people are hurting one another, the planet is rampant
with injustices, whole societies plunder groups of their own people,
mothers imprison sons, children perish while brothers war. O, woe."

WHAT IS THE MATTER WITH THAT, IF IT IS WHAT YOU WANT TO DO?

"But nobody wants it! Everybody hates it."

OH. WELL, THEN STOP.



Thu, 29 May 1997 04:05:22 GMT  
 C++ too slow for scientific computation


I'm really not normally one who would defend C++... I'm one of those
educated critics of the language, having liked the language until I
had to do some serious work in it. *But*, I'm also not one to let
unexplained, possibly invalid criticisms slide by.

Julian> Some timings of programs written in C, FORTRAN and C++ have
Julian> been published in an article in the last "Computers in
Julian> Physics" (Nov/Dec '94).

Julian> The results, in a nutshell, are that C++ times are much slower
Julian> than C on all platforms but the Cray C90. And C is uniformly
Julian> 1.25-2x slower than FORTRAN.

The information presented here is ridiculously incomplete.

Are the three programs the same? That's a crucial question. When you
start using C++, it's natural to start taking advantage of some of the
neat features of the language - most of which have an efficiency
cost. So if you're talking about code that directly operates on an
array in fortran, and operates on class based code in C++, or code
that makes heavy use of constructors/destructors in C++, then you're
running more complicated code in C++ - so of *course* it'll be slower.
(Never underestimate the effect of constructors - I've seen carelessly
written constructors for user written array classes containing user
written complex types that make the O(n^3) matrix multiply become
O(n^5)! You've got to be *careful* with those things, and make sure
that you really understand when they'll be called. The example I'm
thinking of was cause because the programmer forgot about how many
constructor calls were going on to generate and destruct temporary
values.)

Now, in general, C code does often run slower than Fortran, because
Fortrans limited data structures make it possible to perform
optimizations that are inhibited by pointer use in C. (In general, it
is easier to prove no-alias'ing on a variable (or array subscript) in
Fortran than it is in C (or C++). So that much is reasonable, although
I'd still be quite surprised if a direct C translation of Fortran code
is really signficantly slower. (If you go from array code to array
code, and don't introduce any pointer variables, then I'd expect the
code to run very similarly, unless the compiler authors are lazy.)

But I'm particularly suspicious of the C++ results, given that you
don't tell us enough...

Julian> No mention is made of code size. However the hearsay is that
Julian> C++ executables are much larger than FORTRAN ones, which are
Julian> them- selves much larger than they need to be.

I really hate to see *hearsay* used to condemn a language. There's lot
of stuff you can say against the language... TONS of valid criticisms
of the language, the features, and the way it was designed. But
hearsay about code size is NOT a valid criticism.

I'd be very surprised to see a signficant difference in code size
*given equivalent code*. I'd expect to see a difference if the program
was written to use the advanced features of C++...

        <MC>
--
|| Mark Craig Chu-Carroll: <MC> || "There is no such thing as a problem
|| CIS Grad, U of Delaware      ||  without a gift for you in its hands. You
|| PGP Key Available, by finger ||  seek problems because you need their



Fri, 30 May 1997 02:19:30 GMT  
 C++ too slow for scientific computation

Quote:


> : Some timings of programs written in C, FORTRAN and C++ have been
> : published in an article in the last "Computers in Physics" (Nov/Dec '94).

> : The results, in a nutshell, are that C++ times are much slower than
> : C on all platforms but the Cray C90. And C is uniformly 1.25-2x slower
> : than FORTRAN.

>         Of course, this all depends on the relative skills of the
> programmer(s) in these languages.  I daresay that if I was forced to
> code a project in fortran tomorrow, it would probably run pretty
> slowly.  I'd probably spend a long time figuring out how to code up a
> linked list, for example.

You should read the article I referred to. Then you would know what
tasks are being carried out and how they programmed them.

        [ lots of my stuff deleted ]

Quote:
>         Hmmm.. I dunno.  I'm guessing that you're writting pretty
> simple programs here.  What happens when new entities are being
> created in the program?  Suppose you need to stick information into a
> B-tree?  Wanna insert a skip list for that extra speed?  Code up one
> of these in C++( or get a library ) and it's yours forever; how will
> you do that in fortran?  How will you define complex relationships
> between entities?

Very few scientific/technical/numeric programs do any of this.

--
Julian V. Noble



Fri, 30 May 1997 05:43:04 GMT  
 C++ too slow for scientific computation


 :


 : Julian> The results, in a nutshell, are that C++ times are much slower
 : Julian> than C on all platforms but the Cray C90. And C is uniformly
 : Julian> 1.25-2x slower than FORTRAN.

 : I'd be very surprised to see a signficant difference in code size
 : *given equivalent code*. I'd expect to see a difference if the program
 : was written to use the advanced features of C++...

You should read the article.  The reason that C++ was discussed is that
because of its ability to overload operators, etc....  it is easier to code
a complex expression because of all the complexity is hidden by the by the
use of special classes and operator overloading.  For example, if A is a
matric and v is a vector, on can write something like:

    result = A * v;

in C++, where one would have to perform the appropriate subscripting in
FORTRAN and C.  The article basically reported the performance hit by using
this simple notation.   As you mention, and as the article pointed out, C++
lost because of the implicit constructor/destructor calls.

Also, as you say, C can be as fast as FORTRAN provided the C routines are
coded properly.   It just takes less thought when using FORTRAN because the
compiler can usually do a better job of optimization.    
--
     _____________
#___/John E. Davis\_________________________________________________________
#


#   office: 617-735-6746
#



Fri, 30 May 1997 16:50:21 GMT  
 C++ too slow for scientific computation


[more deleted]
|>   [ lots of my stuff deleted ]
|>
|> >         Hmmm.. I dunno.  I'm guessing that you're writting pretty
|> > simple programs here.  What happens when new entities are being
|> > created in the program?  Suppose you need to stick information into a
|> > B-tree?  Wanna insert a skip list for that extra speed?  Code up one
|> > of these in C++( or get a library ) and it's yours forever; how will
|> > you do that in fortran?  How will you define complex relationships
|> > between entities?
|>
|> Very few scientific/technical/numeric programs do any of this.

  There is a tendency to apply this false logic to scientific programming:
few non-scientific programs use sophisticated numerical techniques,
therefore scientific programs use sophisticated numerical techniques
exclusively.  These days, even the first phrase is wrong: from Wall Street
to movie graphics, numerical work is no longer the sole province of
science.  And the conclusion has never been true except for small
scale projects and the (theoretical) projects of numerical analysts.

  Today's innovative and exciting scientific programs use a wide range
of programming techniques to tackle interesting problems.  Traditional
numerical techniques are still essential, but they are not adequate
for real problems.

--
John.


H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598



Fri, 30 May 1997 21:38:14 GMT  
 C++ too slow for scientific computation

Quote:

>how I would do it.  If you are making heavy uses of linked lists, I doubt
>that you are doing heavy numerical programming--- the kind that
>computational physics deal with.  The fact is that numerical programming
>makes HEAVY use of arrays and very little use of linked lists. The emphasis

        Offhand, I can think of one use for linked lists: very large
sparse matrices (say, a 10e9 x 10e9 matrix where 10e10 entries are
non-zero).  I don't know if anyone actually works with matrices that
large, though.

        Out of curiosity, how do people write sparse matrix routines
in Fortran?  This seems to be pretty difficult if no upper bound can be
given on the number of non-zero entries.

        Andrew Kuchling



Sat, 31 May 1997 02:06:33 GMT  
 C++ too slow for scientific computation



|>  : : Some timings of programs written in C, FORTRAN and C++ have been
|>  : : published in an article in the last "Computers in Physics" (Nov/Dec '94).
|>  :
|>  : : The results, in a nutshell, are that C++ times are much slower than
|>  : : C on all platforms but the Cray C90. And C is uniformly 1.25-2x slower
|>  : : than FORTRAN.
|>  :
|>  :         Of course, this all depends on the relative skills of the
|>  : programmer(s) in these languages.  I daresay that if I was forced to
|>  : code a project in fortran tomorrow, it would probably run pretty
|>  : slowly.  I'd probably spend a long time figuring out how to code up a
|>  : linked list, for example..
|>
|> I think that you are missing the point.  Most computer science students are
|> not familiar with the needs of physicists and others doing numerical
|> computations which the article in CIP dealt with.  This ignorance is almost
|> always the source of the pointless C,C++ -vs- FORTRAN flame war war.
|>
|> The most common non-scalar data type using in numerical programming is the
|> array type. It is not the linked list.  Sure it would be very difficult to
|> write a linked list routine using only f77--- right off hand, I do not know
|> how I would do it.  If you are making heavy uses of linked lists, I doubt
|> that you are doing heavy numerical programming--- the kind that
|> computational physics deal with.  The fact is that numerical programming
|> makes HEAVY use of arrays and very little use of linked lists.

   This simply is not true. Scientists doing finite element analysis, image
processing, protein folding, any kind of simulation, and so on and so on
do heavy numerical programming and they do not use full rank scalar
matrices exclusively.  The hackneyed full-rank scalar matrix programs
have been taught in our schools and used in academic demonstrations
for so long that they have now been identified as the canonical scientific
programming technique.  The real world is just not that simple.  

  If a scientist is faced with a problem that can be easily solved by
manipulating full-rank matrices exclusively, the most effective approach
is to prototype with Mathematica or Matlab and program in FORTRAN.
Once less-trivial programs are tackled, an effective approach leaves
the matrix work in FORTRAN and calls FORTRAN from C++.  A special purpose
language always beats a more general purpose language in the special
field.

--
John.


H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598



Sat, 31 May 1997 03:28:40 GMT  
 C++ too slow for scientific computation

Quote:

>I agree with you that things are not that simple and that many programs use
>numerical techniques to solve equations (e.g., find spline coefficients,
>etc...).  However, I am curious about whether the main stream physics
>community uses linked lists, etc... (I am singling out this group because
>the thread was started based on an article in Computers in Physics which is
>more/less targeted at physicsists).  To my knowledge, FORTRAN is still the
>{*filter*} language used by this particular group and, to be honest, I have
>not seen a linked list implemented in f77 without going outside the language
>or using tricks.  This leads me to believe that linked list data structures
>are just not that important for most FORTRAN programmers.  Perhaps if f77 had
>support for such structures (I believe f90 does but I do not think that f90
>is as pervasive as f77), then I would  probably not make such a statement.

Excuse me, please, but what is what is supposed to be particularly difficult
about implementing linked lists in fortran?  I don't know about f77 (I stopped
using fortran before f77 became really popular) but we used to do linked lists
(and much fancier data structures) all the time in f66.  The annoying thing
about fortran was the lack of a record type and the fact that sizes have
to be pre-allocated.

I suppose you can count using an array index as a stand-in for a pointer as
a trick but it seems pretty fundamental to me.

--
There are features that should not be used.     | Richard Harter, SMDS Inc.
There are concepts that should not be exploited.| Phone: 508-369-7398
There are problems that should not be solved.   | SMDS Inc. PO Box 555
There are programs that should not be written.  | Concord MA 01742



Sat, 31 May 1997 15:46:17 GMT  
 C++ too slow for scientific computation

:  :    This simply is not true. Scientists doing finite element analysis, image
:  : processing, protein folding, any kind of simulation, and so on and so on
:  : do heavy numerical programming and they do not use full rank scalar
:  : matrices exclusively.  The hackneyed full-rank scalar matrix programs
:  : have been taught in our schools and used in academic demonstrations
:  : for so long that they have now been identified as the canonical scientific
:  : programming technique.  The real world is just not that simple.  
:  :

: I agree with you that things are not that simple and that many programs use
: numerical techniques to solve equations (e.g., find spline coefficients,
: etc...).  However, I am curious about whether the main stream physics
: community uses linked lists, etc... (I am singling out this group because
: the thread was started based on an article in Computers in Physics which is
: more/less targeted at physicsists).  To my knowledge, FORTRAN is still the
: {*filter*} language used by this particular group and, to be honest, I have
: not seen a linked list implemented in f77 without going outside the language
: or using tricks.  This leads me to believe that linked list data structures
: are just not that important for most FORTRAN programmers.  Perhaps if f77 had
: support for such structures (I believe f90 does but I do not think that f90
: is as pervasive as f77), then I would  probably not make such a statement.

As a postgrad physicist who  works exclusively in C++ I have to suffer the
pains of the C++/Fortran argument regulally and the only conclusion I have
been able to come to is that most physicists seem to argue from a position of
ignorance.  The lack of dynamic memory handeling in F77 means that the
general problem is either not solved, or is sloved by the use of the
larges data region that is to be considered with a fresh compile for a
different case.  The linked list is easily created as an array so long
as the maximum number of links is known, and since most physicists have
never used anything other than Fortran(except maybee basic) This is no
longer considered a problem, or even unusual.

The problem with the transition to C++ from Fortran for numerical work is
both  the obvious small percentage drop in pure performance and the
difficulties in design.  The average Fortran program appears to be a big
'hack'  the problems are sorted on the way down the subroutine tree, you
do not need to consider 'design' at all; the average C++ progrem that is
being written with the intent of reuse requires probably more time being
spent on the overal design than is spent on the code itself.  This is not
the way Fortran programmers seem to think.  Programming is not taught to
physicists in this way -- it is difficult to see the design aspects within
CompSci courses, never mind the 'just get it to run' type of programs that
the programmer who is not concerend with style of his program is taught.

The problem then is not the language but that the user needs to be convinced
that what C++ offers is needed, and then ( once the language is learned)
that design is the key element, not code.

Anyhow,
Stephen.



Sat, 31 May 1997 21:52:37 GMT  
 C++ too slow for scientific computation

: You should read the article I referred to. Then you would know what
: tasks are being carried out and how they programmed them.

        Hmm.. Perhaps.  I hardly expect the entire net community
to do so, however, so, if you're going to bash a language on netnews,
I think it's perfectly okay to expect you to give a little more
background on the tests that were done.

:         [ lots of my stuff deleted ]

: >         Hmmm.. I dunno.  I'm guessing that you're writting pretty
: > simple programs here.  What happens when new entities are being
: > created in the program?  Suppose you need to stick information into a
: > B-tree?  Wanna insert a skip list for that extra speed?  Code up one
: > of these in C++( or get a library ) and it's yours forever; how will
: > you do that in fortran?  How will you define complex relationships
: > between entities?

: Very few scientific/technical/numeric programs do any of this.

        That's true--because they're often written in fortran.  I've
been involved in a few projects that used c++ for scientific
computing, and this kind of thing was used quite a bit.  I might
suggest that you don't think of these things as useful, because you
haven't been using a language that supports it.  I'd hate to
write a scientific program without access to canned data structures,
myself.

--
------------------------------------------------------------------------------

| Laboratory for advanced computing      |      My employer barely KNOWS me. |
------------------------------------------------------------------------------
And at that point, he did not know if he was a man who had been
imagining he was a god or a god playing at being a man.  Thus was his
illumination perfected.



Sat, 31 May 1997 08:29:13 GMT  
 C++ too slow for scientific computation

: The most common non-scalar data type using in numerical programming is the
: array type. It is not the linked list.  Sure it would be very difficult to
: write a linked list routine using only f77--- right off hand, I do not know
: how I would do it.  If you are making heavy uses of linked lists, I doubt
: that you are doing heavy numerical programming--- the kind that
: computational physics deal with.

        For some applications, sure, arrays are king.  I'm not saying
that they're not.  I'm saying that there is a certian chicken-and-the
egg question, and I think( IMHO, of course ) that the reason that so
many physics applications are array-based is, in part, because they
are written in fortran.  I imagine that many( I'm not saying most or
all ) of them, if they were written by a physicist with only C++
coding experience, might make good use of data structures for extra
efficency.

: The fact is that numerical programming
: makes HEAVY use of arrays and very little use of linked lists. The emphasis
: of the article was on using arrays in FORTRAN, C, and C++. FORTRAN is the
: clear winner here with C a close second.  With the respect to C++, the
: article deal with operator overloading, etc...  C++ lost BIG here with
: regard to the speed of doing array manipulations.

        Okay, at least I know what the test was now. :).

:  :         I'm just saying that "speed of prototyping code" is not merely
:  : realted to compile time.  I can code a hash table in a few seconds( I
:  : have a template ) in c++, possibly making my program much faster.  How
:  : long will this take in FORTRAN?

: Again, you are failing to understand the real issue here.  Comparing FORTRAN
: and C++ this way is somewhat like trying to use the argument that an Indy
: 500 race car driver should use a fuel efficient 4 cylinder honda because he
: would have to make less pit stops for refueling.

        I guess I am missing something.  I have no idea how you came
up with the honda example from what I said.  He was saying that
fortran programs took less time to prototype because of comile times,
and I said that compile times does not fast prototyping make.  Could
you exaplin your interpretation?

: `Speed of prototyping' and
: `coding hash tables' are not important for this kind of programming.

        Hmph.  The first programmer seemed to feel that speed of
prototyping was important, and I was replying.  If you do not have
anything constructive to say about that( aside from a completely unrealted
comparison to race cars ), well..

        And, if you never find a use for hash tables, I think this is
a fault of you language of choice, or your programming skills.
Which one is it? ;)

: --
:      _____________
: #___/John E. Davis\_________________________________________________________
: #


: #   office: 617-735-6746
: #

--
------------------------------------------------------------------------------

| Laboratory for advanced computing      |      My employer barely KNOWS me. |
------------------------------------------------------------------------------
And at that point, he did not know if he was a man who had been
imagining he was a god or a god playing at being a man.  Thus was his
illumination perfected.



Sat, 31 May 1997 08:42:34 GMT  
 C++ too slow for scientific computation

Quote:


>  :    This simply is not true. Scientists doing finite element analysis, image
>  : processing, protein folding, any kind of simulation, and so on and so on
>  : do heavy numerical programming and they do not use full rank scalar
>  : matrices exclusively.  The hackneyed full-rank scalar matrix programs
>  : have been taught in our schools and used in academic demonstrations
>  : for so long that they have now been identified as the canonical scientific
>  : programming technique.  The real world is just not that simple.  
>  :

> I agree with you that things are not that simple and that many programs use
> numerical techniques to solve equations (e.g., find spline coefficients,
> etc...).  However, I am curious about whether the main stream physics
> community uses linked lists, etc... (I am singling out this group because
> the thread was started based on an article in Computers in Physics which is
> more/less targeted at physicists).  

I have used linked lists, although I generally prefer to replace
them with a list of pointers or a stack (either of which, for most of
my applications, will do the job using less memory and much faster, to
boot). Both of these are especially easy in Forth (my language of pref-
erence). My most serious attempt to use a linked list was in an
indexing routine (text processing). Since the list was doubly linked
and I used binary search for insertion, the index came out sorted and
the running time was n log(n)--so far so good. However, when I tried
a hashed dictionary and sorted afterward using Quicksort, the running
time was reduced 4-fold. There was just too much overhead in searching
through a linked list, even when I hand-coded the relevant routines.

I would guess that except for people dealing with large sparse
matrices, most physicists have never used a linked list, even if they
have heard them mentioned. There are some sparse matrix programs in
"Numerical Recipes in FORTRAN" but I haven't studied how they manage
the storage. Almost certainly not with a linked list, however, which in
FORTRAN _could_ be simulated with integer functions but which would
then take a big performance hit because the calling overhead is so
large.

Complex finite element calculations demand dense matrices, for which
the efficient storage scheme is the standard one, not a linked list.

Quote:
> To my knowledge, FORTRAN is still the
> {*filter*} language used by this particular group and, to be honest, I have
> not seen a linked list implemented in f77 without going outside the language
> or using tricks.  This leads me to believe that linked list data structures
> are just not that important for most FORTRAN programmers.  Perhaps if f77 had
> support for such structures (I believe f90 does but I do not think that f90
> is as pervasive as f77), then I would  probably not make such a statement.
>      _____________
> #___/John E. Davis\_________________________________________________________
> #


> #   office: 617-735-6746
> #

I assure everyone that I was not trying to start a flame war, even though
in my heart of hearts I may believe that most of the world's ills--Bosnia,
Haiti, Newt Gingrich--can be traced to C++  ;-)

I merely felt that in the context of deciding which language to use
for a given purpose, all relevant information should be considered,
such as an article pointing out that physicists who might want to use C++
for whatever reason--quicker development, reuse of code, better maintain-
ance, better clarity--over FORTRAN, the standard, should be aware they
will have to accept severe execution speed penalties for typical programs.

--jvn
--
Julian V. Noble



Sun, 01 Jun 1997 01:42:59 GMT  
 C++ too slow for scientific computation


:  :


:  : Julian> The results, in a nutshell, are that C++ times are much slower
:  : Julian> than C on all platforms but the Cray C90. And C is uniformly
:  : Julian> 1.25-2x slower than FORTRAN.
:  
:  : I'd be very surprised to see a signficant difference in code size
:  : *given equivalent code*. I'd expect to see a difference if the program
:  : was written to use the advanced features of C++...
:  
: You should read the article.  The reason that C++ was discussed is that
: because of its ability to overload operators, etc....  it is easier to code
: a complex expression because of all the complexity is hidden by the by the
: use of special classes and operator overloading.  For example, if A is a
: matric and v is a vector, on can write something like:

:     result = A * v;
:    
: in C++, where one would have to perform the appropriate subscripting in
: FORTRAN and C.  The article basically reported the performance hit by using
: this simple notation.   As you mention, and as the article pointed out, C++
: lost because of the implicit constructor/destructor calls.

Didn't we go over this recently here?

*IF* we had garbage collection, one would write MAT and VEC as reference
types, and result = A*v would compute A*v store in a temporary like before,
but the assignment would only change a pointer.

--

-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".



Sun, 01 Jun 1997 09:44:09 GMT  
 C++ too slow for scientific computation

:  ...
:                                                         Perhaps if f77 had
: support for such structures (I believe f90 does but I do not think that f90
: is as pervasive as f77), then I would  probably not make such a statement.

But if so, might not also the programming skills of Fortran users _also_
have advanced into the same areas that everyone else considers valuable?
Seven{*filter*} years is a long time to keep your head in a cave.

- Lenny Gray -



Sun, 01 Jun 1997 08:32:26 GMT  
 
 [ 23 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Eiffel as a substitute for Fortran in scientific i computations

2. m2 for scientific computation

3. m2 for scientific computation

4. numeric computation in Eiffel and C++

5. C++, fortran, Harwell Boeing format and eigenvalue computations

6. C++ in scientific programming ?

7. C++ in scientific programming ?

8. Fortran vs C++ for scientific computing

9. any move to OOP/C++ in scientific code?

10. any move to OOP/C++ in scientific code?

11. Workshop on C++ for Scientific Computing

12. C++ for Scientific Computing

 

 
Powered by phpBB® Forum Software