Pierre Hugonnet wrote:
> Swietanowski Artur wrote:
> > I support the above statements:
> > a) speed and ease of development are much more important than high
> > levels of optimization,
> > b) the improvements of theoretical knowledge can lead to reduction
> > of computational complexity (say, by reducing the power in
> > the polynominal complexity case) whereas compiler optimization
> > may just provide linear reductions.
> >
> > In numerical optimization / OR environment I work in a large part
> > of the new software, including commercial, is already written in C
> > or C++. Fortran has to reverse the trend to stay alive much longer.
> > And I can tell you, switching from a fully object oriented language
> > like C++ to F90 is mostly a big and unpleasant step back. For now,
> > at least.
>
> Sorry, but when a program is 50% slower and requires 100% more memory
> with f90 compared with f77, you have some difficulties to make it
> included in industrial packages.

You didn't get the point: some F77 codes would never come into
existence because it would take too many man-hours of labour to
write them.

You also didn't get the other point (complexity). An O(n**2)
algorithm in all non-trivial cases will be better than O(n**3)
or O(e**n). Achieving better complexity practically always
requires more complex processing. And compiler optimization
simply can't reduce the complexity, just scale down the running
time, which corresponds to moving from O(e**n) to O(0.1*e**n).
That's going nowhere.

So with a better language you may end up:
a) having a running program,
b) having lower algorithm complexity and finally
c) having after all a faster program, too.

I repeat: even in the (relatively simple) area like linear
programming many commercial and research codes now are written
in C (CPLEX a prominent case, LOQO another good example).
I can name many other examples from many other fields of research.

> I need only a few and simple OO features. I don't need powerful
> pointer features, I don't need C++ classes... What I need is an
> *efficient* and easy to write and read code.
> Seismic data processing consists in the application of generally
> quite simple algorithms to a *huge* amount of data.

That's a very narrow application field. Numerical optimization
applies huge amounts of highly complex processing to relatively
small amounts of data. And most optimization problems we'd like
to solve are unsolvable because we need better algorithms (and
not better compiler optimizations).

> Each langage has a specific domain of
> applications. Scientific computing needs a langage: f77 was a good
> one for that (much better than C),

Many researchers think otherwise and voted with their feet.

> f90 is still a good one in my
> opinion (there are still optimization problems with compilers, but
> I hope this will be better and better). But please don't transform
> fortran into C++, or we will have to create a new langage to
> replace Fortran! If you need C++ features, then use C++ or Java
> (in the same way I've always said to C fanatics to use Fortran for
> scientific computing). Should Fortran also include all features
> from Lisp, Prolog, or in other specific langages ?

No. I just say that Fortran should be a good lanuguage for all
numerical analysts, engineers, researchers and not just for
seismic data analysis. I see it as a more democratic view.

As I work in the field for which Fortran is supposedly designed
I feel free (in fact, obliged to) let the other interested parties
know what I need and expect from the language.

> I would like to be sure to that any intruction I use will be
> fully optimized (if find it exhausting to always asking myself:
> wouldn't it be more efficient to write this with a do loop rather than
> with this new and nice compact instruction?).

You should memorize some famous quotes along the lines of:
 "Premature optimization is the root of all evil" or
 "Make it run than make it run fast" (with a longer version
 also available).

> <large snip>
> In f90 I like (and use) array syntaxes, genericity, interfaces. I also
> like, but use less, pointers. I like a lot parallel oriented features,
> because it allows to write easy to parallelise (by compilers) code
> (parallelisation is much more important for me than OO features!).

1) Learn and use what you like and need. Ignore the rest. And don't
   tell others (who may need more) to use another language.
2) Automatic parallelization works best for so-called embarassingly
   parallel problems. In more complex cases it's again down to
   the algorithm (which often has to be totally redesigned
   or simply replaced by a completely different one).

In my problems automatic parallelization (as allowed by F90 now)
is 100% useless. I'm sorry about that because it would make my
life easier if I could use it. But that's just a fact. And I'm
not going to argue with a fact.

Regards,
----------------------------------------------------------------------
Artur Swietanowski mailto:[log in to unmask]
Institut fuer Statistik, Operations Research und Computerverfahren,
Universitaet Wien, Universitaetsstr. 5, A-1010 Wien, Austria
tel. +43 (1) 407 63 55 - 120 fax +43 (1) 406 41 59
----------------------------------------------------------------------


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%