FEEDBACK

Two months after the conference a spirited free-for-all broke out on the local electronic bulletin board. Reformatting from the email msgs bulletin format to L^ATEX below required me to exercise small editorial judgments that detract only slightly from exchange:

Bill Harlan:

I'm sorry that F90 has sidetracked your project because I can't find anyone outside of the SEP interested in using F90. Is it really easier to learn to use F90 than C? Which is more likely to be useful after graduation?

If you use C++, then you can use as little of it as you prefer, and know that additional power is available should you need it. (Some will say that F90 is appropriate for parallelism. Any rules for parallelism you learn this year are unlikely to be useful in five years. Students shouldn't be worrying much about efficiency anyway.)

David Lumley:

Which language? Probably the one that lets you code your ideas most efficiently, and can be road-tested on full size data sets in reasonable run times. This is some non-unique combination of user preference and run-time efficiency. Dave Nichols and I had an interesting experience with multiple suppression: we used Dave's C++ code to find the best objective function weighting scheme, etc., and used my Fortran code with those optimal parameters for the full-size runs on the Mobil AVO data because it was 30x faster than Dave's optimized C++ code. Both C and Fortran were useful.

Specific parallelizing rules maybe. Generic rules and concepts should be valid longer.

Depending on what you're doing, learning to develop efficient code can be extremely useful as a student. If you're scoping out something abstract like the behavior of an objective function, fine. But nobody will care how great your nifty C++ code is if it takes 24 cpu hours to run on a single shot gather (e.g., who really cares about 1-D full waveform inversion?). Learning to develop prototype code that can do something new efficiently is basic training for an applied research job in the industry. People who have this expertise when they go job hunting have a huge advantage over others who may also be bright, but can't test their ideas on data efficiently.

Dave Nichols:

I would hesitate to use the word ``optimized" about the C++ code we used. It was compiled with optimization on but it wasn't designed for fast operation. It was designed for maximum flexibility.

I could write a C++ code for the velocity stack inversion problem that gets to within a factor of two of Fortran code. It won't be quite as flexible as the code we had but it is still be usable within the C++ operator framework.

So my conclusions are:

1.

There is always a tradeoff between generality and efficiency.

2.

It is certainly true that Fortran compilers are better at optimizing many problems.

3.

Out of the factor of 30$\times$ I would say that 2-3$\times$ was due to C++ vs Fortran, 2-3$\times$ was due to the way we designed the CLOP classes (lots of creation and deletion of objects in every iteration) and 4-7$\times$ was due to the use of a very general code. It is possible to write much less efficient code in C++ than in Fortran because of all the extra options you get!

4.

Why did we use David's Fortran code rather than optimize the C++? Because once we had found a good set of parameters he wrote the Fortran code in a morning!

(This doesn't address the parallelism issue at all.)

Biondo Biondi:

I think that we should not cast GOON as an F90-based system. I believe that one of the potential advantages of GOON is to exploit C++, F90 and C (yes C!) for what they do best.

C++ orchestrates the whole application, and enables us to write general and reusable code for the most of the constituent blocks, such as optimization algorithms and vector space functions and operators. Even if we write operators in F90, we can reuse them and combine them within the same application only thanks to the abstraction capabilities of C++.

Writing seismic operators in F90 instead of C/C++ is arguably easier in the absolute sense, but it is certainly easier for most SEPers. Being able to run them fast because compilers are available that can optimize/parallelize such F90 operators without much parallel/multi-threading coding is an additional, and I believe important, benefit.

All the low level I/O libraries for both the RGF and IGF vector classes are written in C. Such coding is what C was invented for, and it is where it adds the most value.

The potential problem with GOON is that we may have tried to be too smart in our effort of exploiting all the available languages at their best, and built a system that is difficult to use and maintain.

My hunch is that the whole team has succeeded in beating the odds, and actually GOON will be fairly simple to learn for new users, and maintainable, at least by their initial developers.

When the first ``pure" users will try to use GOON (soon I hope) we will have some answers to these questions and have better feelings whether we have created a monster or a winner. I am very optimistic!

Bill Harlan:

To SEP students: I think your continued use of F90, and inevitable dependence on it, will seriously limit the number of your collaborators. The only arguments I have heard in favor of F90 are (1) ease of use and (2) parallelism. As I said before, C and C++ are not harder to learn at a level comparable to F90, and you have much more potential to learn over the years.

No, I do not think the ``general principles" you learn from F90 parallelization will continue to be useful. The sort of parallel machines you are likely to use (the Power Challenge) are not massively parallel. On 8 to 16 nodes, the most popular parallel styles use things called ``threads" and ``semaphores" (or worse PVM), which you are unlikely to see in F90 anyway. These styles are too complicated and are evolving too rapidly for students to keep up with, unless you have a strong interest in computer science.

Again, C is EASY to learn and use. Read Kernighan and Ritchie on a weekend. Use it like Fortran for a while. Don't feel obliged to use all the gadgets in C++ any time soon. You've got years to pick up more programming tricks. But start out on a path with a little more potential for growth. Do it for your own sake, even if group projects continue to use F90. Believe me, C[++] will look much better on your resume, will not take any more of your time, and will continue to be useful when you graduate.

Matt Schwab:

I learn a new language when it changes my way of looking at my problems. In comparison to a procedural language, a strong object oriented language (C++, Java) does offer a very distinct viewpoint. Object orientation might allow a good researcher to tackle problems beyond ``do looping".

For ``do looping" I like to use Fortran77: I know it already and it parallelizes fine on our Power Challenge (not necessarily on other parallel machines). Do I need to learn F90?

If I had to learn ``a first computer language" I hope I would start with C and/or C++ (as I suggested to Curt recently). It is a good language to know and C++ and Fortran are easy to add. Even new languages (e.g. Java) try to ease the transition for C programmers.

What language facilitates good collaboration? That depends on who you want to collaborate with: there exists a lot of F77 code (especially at SEP). On the other hand, the non-SEP researcher I collaborated with at TRIP (Rice) or SCCM (Stanford) coded C++ and C. All the code that I saw at TOTAL was C or C++. F90 and Java are ``young" languages and I have hard time predicting their success. Java seems to be more fun ... and I like fun.

I feel C-C++-Java is the way to go in the long term. Biannual SEP reports, however, are a very short term thing. *Smiles*.

(Bill, I am glad you raise these issues because I wish I had learnt more about C, C++ in my early days at SEP. )

Sergey Fomel:

What language facilitates good collaboration?

This question (related to the concept of reproducible research) is one of the most important to ask ourselves. Jon Claerbout has been using Fortran in teaching for more than 20 (25?) years. Nothing made me more enthusiastic than watching the whole building of TDF, BEI, PVI, etc. raising up from scratch with no locked rooms. That effect owes a lot to Fortran's clarity.

Reproducible research means an ability to take other people's code, understand 100% of it immediately (as a precise description of the algorithm), and modify it to continue the previous (unfinished) research. If we lose any part of this ability, SEP may become different from what it is now (moving into CWP's shadow?)

It is true that Fortran77 suffered from the lack of object-oriented features. Luckily, most of them appear in Fortran90, which is quite popular in the engineering world and flexible enough to solve all of our problems.

Learning how to solve problems is more important than including computer languages in your resume. (Don't our future employers think so?) At the learning stage, we need a language, which is object-oriented but yet easy for exchanging codes among different people. Am I wrong thinking that C++ doesn't meet both criteria?

Being as tired of the F90/C++ discussion as anyone else, I just wanted to present a student's point of view. No offense to religious C++ers.

Bob Clapp:

I feel a clarification is necessary: The idea that GOON locks us into Fortran90 is wrong. The base of GOON is written in C++, we have an entire SEP77 style class also written in C++. All GOON offers as opposed to HCL is that it is also possible to write in Fortran90. Someone wanting to do all their work in C++ could still easily use GOON, the only current limitation imposed is that our current interaction with SEP90 is only written in Fortran90.

Stew Levin:

Shuki raises an interesting example when he mentions his FPS work as being of little practical value two years after graduation. (Mine was three years ...) In my own case, the concepts behind the FPS programming (pipelining operations, vector functions, and asynchronous communication) still serve me in good stead, in support of David Lumley's point. Similarly with the NCUBE parallel computer that used to be in in the basement of computer science. I am happy though that for the most part the balance between geophysics and computing has shifted away from computing over the past decade at SEP.