 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Munir Bhatti
Guest
|
 Posted: Sat Jul 15, 2006 2:08 am Post subject: FORTRAN -> C++ -> multithread |
 |
|
Hi All,
I've been working with a research group of physics people who are
prefer *gasp* FORTRAN. In the beginning this was important as we needed
to include and merge legacy code. Since then, however, the program has
grown in complexity, the legacy code has been superceded in most cases
by new code, and special FORTRAN functions that we're using, it turns
out, also appear in the C/C++ GNU Scientific Library (GSL) in
equivalent-or-better form.
For the sake of code organization via classes, access to GSL, full
debugger support (not to be found with g77), and the option to
multithread, I'm considering porting the whole enchilada to C++. I'd
take the opportunity to rewrite using user-defined classes and the GSL
functions, greatly simplifying the code--thus cooking a new enchilada.
Then, since this program uses gobs of compute time, I'm considering
making each particle trajectory (they're non-interacting) a thread and
run this on a cluster.
In preparation, I've read three C++ texts and written a handful of
programs. C++ uses the class concepts I learned about in Java and also
offers the complex-valued math support we've enjoyed with FORTRAN. So
I'm thinking the port won't be difficult. Am I wrong? Am I hopelessly
naive? Please let me know if you think this is too ambitious and, if it
is a sane approach, what path might make the process easier (e.g.
paradigms, planning methods, books, forums, etc.).
Thanks,
-Munir
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
Le Chaud Lapin
Guest
|
| Posted: Tue Jul 18, 2006 7:43 am Post subject: Re: FORTRAN -> C++ -> multithread |
|
|
A Marlow wrote:
| Quote: |
I'm considering porting the whole enchilada to C++. I'd
take the opportunity to rewrite using user-defined classes and
the GSL
In preparation, I've read three C++ texts and written a handful of
programs.
I'm thinking the port won't be difficult. Am I wrong?
|
I am going to disagree with the two responses made so far and say...do
it!!! Change to C++!!
Hindsight is 20/20, and you have plenty of that. The code is probably
not pretty if it has undergone revision many times. Your gut instinct
is correct - if you do the rewrite correctly, you will eliminate a
large number of problems with the new code.
Make it cleaner. Make it prettier. Make it faster. Make it more
regular.
And whatever you do, don't treat it as clay that can be combined with
other clay to make a bigger blobs of clay. Programs are discardable.
It is the form which they represent that is not.
The FORTRAN programmes will probably fight you tooth and nail to keep
you from redoing their work. I would suggest you just do it and keep
quiet about it until it is done. Then manage well the
presentation/introduction of it.
Good luck.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Ulrich Eckhardt
Guest
|
| Posted: Wed Jul 19, 2006 4:02 am Post subject: Re: FORTRAN -> C++ -> multithread |
|
|
Munir Bhatti wrote:
| Quote: | I've been working with a research group of physics people who are
prefer *gasp* FORTRAN. In the beginning this was important as we needed
to include and merge legacy code. Since then, however, the program has
grown in complexity, the legacy code has been superceded in most cases
by new code, and special FORTRAN functions that we're using, it turns
out, also appear in the C/C++ GNU Scientific Library (GSL) in
equivalent-or-better form.
For the sake of code organization via classes,
|
What? Why? In particular scientific code is often an algorithm running over
GiBs of data, there is nothing that classes would make easier. Don't use
the OOP hammer unless you also have an OO problem.
| Quote: | access to GSL, full debugger support (not to be found with g77), and
the option to multithread, I'm considering porting the whole enchilada
to C++. I'd take the opportunity to rewrite using user-defined classes
and the GSL functions, greatly simplifying the code--thus cooking a
new enchilada. Then, since this program uses gobs of compute time,
I'm considering making each particle trajectory (they're
non-interacting) a thread and run this on a cluster.
|
Okay, since there is no interaction between threads this is probably the
most trivial form of multithreading.
| Quote: | In preparation, I've read three C++ texts and written a handful of
programs. C++ uses the class concepts I learned about in Java and
also offers the complex-valued math support we've enjoyed with
FORTRAN.
|
Okay, just wondering, what are your backgrounds? What languages do you know
with how much experience in them?
| Quote: | So I'm thinking the port won't be difficult. Am I wrong? Am I
hopelessly naive? Please let me know if you think this is too
ambitious and, if it is a sane approach, what path might make the
process easier (e.g. paradigms, planning methods, books, forums,
etc.).
|
I don't think it is a good idea. You should definitely research ways to use
C++ multithreading to scale better, you should also research if you can
make GSL functions available for better quality (performance, precision,
whatever you want there), but stop there first. The point is that you (it
seems, no offence intended) are a novice in C++, while your colleagues are
not even that but experienced Fortran hackers. So what I'm afraid of is
that the converted code will be bad or at least questionable C++ code that
is then used and enhanced by Fortran programmers. There are many, many
pitfalls in C++ that first need to be learned, so I dare say this is a sure
way to shoot yourself in the foot. Probably this will happen rather later
than sooner, because it is mostly the maintenance that is affected, but it
will happen.
If you still want to or even just try, do it slowly, step-by-step. You will
also have to teach your colleagues a new language (and convince them that
they should learn it).
Uli
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Martin Bonner
Guest
|
| Posted: Wed Jul 19, 2006 4:06 am Post subject: Re: FORTRAN -> C++ -> multithread |
|
|
Munir Bhatti wrote:
| Quote: | Hi All,
I've been working with a research group of physics people who are
prefer *gasp* FORTRAN.
|
There are good reasons for doing so. C and C++ allow you do to a lot
more object aliasing which makes it really hard for a compiler to
optimize. FORTRAN makes such code illegal (undefined behaviour in C++
terms).
Do you really mean FORTRAN? The last standard that refered to that
name was (I think) FORTRAN-IV aka FORTRAN-66. You will probably find
it a lot easier to migrate to Fortran-90 than to C++.
Fortran 2003 directly supports classes etc. If you need object
orientation, that is almost certainly the way to go.
| Quote: | In preparation, I've read three C++ texts and written a handful of
programs.
Um. So it would be a case of the one-eyed man leading the blind.
C++ uses the class concepts I learned about in Java
Only sort of. I believe the Java model is very significantly different |
from C++
| Quote: | and also
offers the complex-valued math support we've enjoyed with FORTRAN.
So I'm thinking the port won't be difficult.
Am I wrong? Am I hopelessly naive?
Rewriting a non-trivial application from scratch (which is what such a |
port entails) is /never/ going to be easy.
I would
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Guest
|
| Posted: Wed Jul 19, 2006 4:17 am Post subject: Re: FORTRAN -> C++ -> multithread |
|
|
Munir Bhatti wrote:
| Quote: | Hi All,
I've been working with a research group of physics people who are
prefer *gasp* FORTRAN. In the beginning this was important as we needed
to include and merge legacy code. Since then, however, the program has
grown in complexity, the legacy code has been superceded in most cases
by new code, and special FORTRAN functions that we're using, it turns
out, also appear in the C/C++ GNU Scientific Library (GSL) in
equivalent-or-better form.
For the sake of code organization via classes, access to GSL, full
debugger support (not to be found with g77), and the option to
multithread, I'm considering porting the whole enchilada to C++. I'd
take the opportunity to rewrite using user-defined classes and the GSL
functions, greatly simplifying the code--thus cooking a new enchilada.
|
Fortran 95 has user-defined types but not inheritance. It is
essentially a superset of Fortran 77. By migrating to Fortran 95, you
can make incremental improvements while still having a working code. If
you try to rewrite the whole thing in C++, you may not know for weeks
or months whether you are wasting your time.
Do you know anything about versions of Fortran more recent than Fortran
77. Your "gasping" suggests you may not. G95 is a free and good Fortran
95 compiler.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
Guest
|
| Posted: Wed Jul 19, 2006 4:30 am Post subject: Re: FORTRAN -> C++ -> multithread |
|
|
A Marlow wrote:
| Quote: | On Fri, 14 Jul 2006 17:08:20 -0400, Munir Bhatti wrote:
I'm considering porting the whole enchilada to C++. I'd
take the opportunity to rewrite using user-defined classes and the GSL
In preparation, I've read three C++ texts and written a handful of
programs.
I'm thinking the port won't be difficult. Am I wrong?
|
I'm sure there will be difficulties. Translation is doable (see
below), but my experience says that "... the whole enchilada ...
rewrite ... won't be difficult ..." often masks:
"I don't understand the code, but the user's guide isn't that thick, so
I'll just implement it with code I do understand."
The result is usually expensive. In some cases it is better, in the
sense of being able to attract new users, but it is also likely to have
dropped/changed enough functionallity that it will alienate existing
users.
1) Translate everything, without rewrite, is doable, if the application
is small or if you can automate most of the translation.
2) Rewriting bite-sized modules is often a good idea.
3) If the code is not already modular enough for (2) to be workable,
consider modularizing the code.
4) If (3) is unworkable, abandon the code. Don't play auto mechanic if
you aren't sure which piece is the disk brake, and which is the
steering wheel. Write a new application, just don't expect it to have
all the same functionallity, at least not initially.
| Quote: | Could be. This sounds like high risk to me. I think a better strategy
might be to wrap the FORTRAN using C++ and to set a rule that all NEW
code
is to be in C++. This keeps the working code in place and provides a
migration path for those engineers that have not yet moved with the
times.
|
I've seen both approaches work. I think it is largely a people issue.
Two approaches I've seen work:
Case A) Computational numerical core remains Fortran. Maintained by
Fortran guys. Well defined Fortran API for access. C++ wrappers on
the Fortran API. C++ (or other languages) provide user-interface,
database-interface, ... .
Case B)
B1: Legacy code was Ratfor->Fortran66->Compiler.
B2: Ratfor->Fortran66->f2c(from netlib)->C. This gives correct, but
unreadable C.
B3: Ratfor->In-house-translator->C++. C++ human-readable &
maintainable, but still procedural. It is link-compatible with f2c,
allowing incremental conversion and testing.
B4: New code is written (and often old code is rewritten) in idiomatic
C++. Source files (simple ones) still exist whose entire history is:
'79: written
'94: translated to C++
Recommendations for translation:
0) The people who are going to have to live with the code better want
it translated.
1) This is a lot easier if your low level I/O is isolated to a few
routines. FORMAT does not translate cleanly.
2) Build prototypes from the bottom up.
SUBROUTINE FOO(X)
INTEGER X(23)
CALL BAR(X(1))
END
You don't know if FOO's argument is 'const' until you know how bar
treats its argument. You'll also want to know if bar treats its
argument as an array or as a scalar. Should you translate the call as
bar(x);
or as
bar(x[0])
?
The translator will want to look at bar's prototype in order to
translate foo, (including the creation of foo's prototype).
3) As much as possible, avoid catering to Fortran idioms that are a
mismatch for C++. For example, 1-based array conventions. You can't
avoid this entirely, but prefer to translate
VEC(FUNC(J)) = 3
to
vec[func(j)-1] = 3;
rather than writing a one-based vec.
HTH
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
