Re: FORTRAN -> C++ -> multithread
Munir Bhatti wrote:
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.
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.
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?
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! ]