That said, I was wondering if anyone thought scientists would ever adopt Fortran's new object-oriented structure? (For those who don't know, new in Fortran 2003 has "Object-oriented programming support: type extension and inheritance, polymorphism, dynamic type allocation, and type-bound procedures.")
I ask this because I have a friend here at Irvine who is trying to rewrite his group's Fortran code so that it is object oriented and thought:
- Object orientivity has traditionally been an argument for scientists to switch from Fortran to C++. (If you don't need something that strong you really should be using Python. :))
- I have a high performance computing book that touts Fortran's biggest pro is it forces numerical programmers to avoid objects because of the overhead they often add to numerical performance.
- One reason Fortran is still used so much is nobody wants to rewrite the codes their group uses as it would take too much time and effort.
- If you are going to object-orient your code, is it really better to re-write it in Fortran 2003, as my friend is doing, or just rewrite in in C++?
- Maybe object-orientivity has less overhead in Fortran compared to C++? For example pointers in Fortran are not allowed to "change type" in Fortran giving them a slight performance edge in their ability to be optimized? Does anyone know if similar types of performance advantages will also carry over to Fortran's object structure?
Fuh Fuh Fuh Fortran? Geez, take me back to the '80s! =:)
ReplyDeleteI have some experience with old fuddie duddy C programmers trying to adapt to C++. It ends up being procedural with a few obvious objects used. The fact that you could mingle the two paradigms muddled the picture a bit. Old habits are hard to break and we know how scientists are with paradigm shifts! =:)
I suspect non-OOP will look at your friend's object oriented code and get frustrated cause it's hard to find where stuff is happening.
"Fuh Fuh Fuh Fortran? Geez, take me back to the '80s! =:)"
ReplyDeleteI know, some languages in science refuse to go away.
How adept is the typical research scientist at programming? Would it accelerate the process to split the work with "real" coders or is the code and the research too intimate?
ReplyDeleteStan,
ReplyDeleteI think the physics community is very good at solving equations and getting correct answers. To do this you have to understand the physics well and have a good intuitive feel of when results make physical sense.
I do not think, working with codes, that they have the best coding practices. Sometimes this is a good thing since sometimes "good practices" sometimes mean you don't get peak performance. Than again, it also means codes code be aren't always well written, modular and easier to use and share.
Find me a CS guy who knows how to use good coding practice, keep things well written and modular without sacrificing any performance, coupled with the ability to understand physics well and have great intuition of if results are physical, this would be great.
It would be nice if the CS departments taught courses on how to get peak performance out of a supercomputer while maintaining great coding practices. The physics community could use such people.
Unfortunately I see little effort by physics department to teach such courses as well. My experience is you take basic coding classes then jump right into research.
Joe and Stan,
ReplyDeleteIn the words of Ed Nather, a long-time professor of astronomy at the University of Texas, "Having a professional design the instrument [or software] for you will get you a skilled, polished, economical design that solves the wrong problem." Scientists write their own codes because the codes are intimately connected with the physics of the problem.
That being said, there are some codes (FLASH comes to mind) that are large enough that they really require software engineers, but for the most part codes are written with moderate to low levels of good-coding-practices.
Nick,
ReplyDeleteUnfortunately, there is some truth to Nather's quote.
Actually, I'll ell you a bit of coding mischief I did this to get the job done. I ran a code with several files that was taking several days on 56 processors to run. I remember reading somewhere that compiling a program broken up into multiple files runs slower than if everything is one huge file.
I literally did a cat file1 file2 file3 .... > bigfile and made a couple minor changes and recompiled the huge code as one file.
Guess what, it actually ran about 30% faster saving me a couple days. :)
Horrible coding technique, but fast.
/me thinks he may convert all the huge codes he can to one giant file for a possible 30% performance improvement. ;)
ReplyDeleteOn the original topic of the post, our code actually uses Fortran 97, which isn't truly object oriented but does allow for things like modules that give some semblance of modern coding practices. The annoying thing about Fortran 97 is that it's not supported in many debuggers and profilers. When we asked the tech support people at several supercomputing centers why they all said that almost all Fortran users are still using Fortran 90 or Fortran 77 - almost none have made the jump to the more modern versions. Why? Tradition of course.
ReplyDeleteHere's another example: we use a spherical harmonic transform to solve our equations which is just an FFT and a Legendre transform. There are some wonderfully efficient FFT's out there but not a lot of Legendre transforms. When the code was first written, Mark Meisch coded up a nice, easy to read Legendre transform which turned out to be extremely slow. Instead we now use a Legendre transform written in Fortran 77 complete with GOTO's and 3 letter variable names, but our Legendre transforms run nicely.
ReplyDeleteIf you think Python is good you should try Ruby.
ReplyDeleteMy vote is "no". We still use Fortran 77 due to legacy libraries, and sometimes Fortran 95 for crunching numbers.
ReplyDeleteIt is a problem, at least in Europe, that grad students are using C++ instead of Fortran. C++ sucks rocks for numerical computing, both in terms of learning curve, robstness and productivity. CERN switched to C++ as the main language for the LHC for the reason that more grad students were familiar with it. They even made a C++ interpreter (yuk), as scientists have fallen in love with interpreted languages. Interpreted languages, with an interactive prompt are easier to experiment with. The choice of C++ is now one of their biggest regrets.
And that brings me to the reason why OOP Fortran will never be a hit: We'll rather use scripting languages for any of that. MATLAB, Python, Mathematica, R, IDL or Perl -- all have their personal favorite. Mixed language programming is becoming the norm. OOP Fortran is a dead end.
But we have to do something to make sure the next generation of science students don't waste their time on C++, Java, F# or whatever is the current hype.
Sturla, thanks for your input. And to be honest, despite everything I said above, I think you may be correct on many points.
ReplyDeleteYes, I am aware of the CERN situation and add "root" is a nightmare.