Subject: CCL:OOP in comp. chem

From: Galen Gawboy <[email-masked]>
Date: Wed, 9 Feb 1994 23:53:18 -0500 (EST)

Netters,

    Like many others I find this topic quite fascinating and I just can't
keep my big mouth shut. Before I voice my opinions I would just like to 
state that I believe that both viewpoints are equally valid depending on
the specific area of computational chemistry you work in. My viewpoint is
that of someone who runs large scale multireference electron correlation
calculations.

> Ferenc brought up this point. 
> >>> Third and most important:
> >>> As you always have a lack of hardware resources, you
> >>> need a compiler which optimizes efficiently.
> >>> Often the raw speed of your calculation is the crucial point.
> >>> FORTRAN compilers have quite a history and are very effective in
> >>> "number crunching" and are essentially bug free.
> >>> The advantage of C++ (or say FORTRAN 90) is that you can handle
> >>> dynamic memory allocations, but this can slow down the program and
> >>> prevent effective optimization.
>
> To which Quentin replied: 
>
> This I really disagree with.  Certainly I always wish my calculations
> will go twice as fast but in reality I probably just have to wait
> for next year's machines. In my opinion the big challenge facing us
> at the moment is verification of correctness not optimization.  If a
> language change makes a program slower by a factor of two or three then
> it is no big deal - that may set us back a year.
> 

   Well, if you run large jobs, speed IS critical. When you submit a proposal
to a super computer center, one of the issues which you must address is that
your codes will make efficient use of the center's resources. On these 
machines, you can oftentimes only count on getting access to ONE cpu. So for
a machine like this, you want the fastest time on a single CPU which you can
manage. Suppose my application code runs at 235 MFLOPS on a single cray CPU.
If it only ran at 78 or 156 MFLOPS it could cost me getting my grant for
time approved. If I was paying cash for the time, I would rather have 235
MFLOPS performance than 156 MFLOPS anyday, so as to get more results/dollar.

   Also most ab-initio packages do not rely on compiler optimization, these
packages are hand tuned for each machine on which they are going to be run
on. This tuning is usually done in the number crunching library routines.

> 
>                                              But if we could introduce
> a better and more robust design that would benefit us for the lifetime
> of the program (which has been ~25years for codes like GAUSSIAN).  

   Here we run into a the harsh realities of the real world. To re-design
and re-implement the major ab-initio packages would optimistically take
8-10 years. What is the probablility of getting funding for such an effort?
What would be the probability of getting this effort funded if the end 
product was going to be 2-3 times slower than what already exists? What
is more likely is that the large codes will evolve. For example some 
ab-initio packages are begining to use C routines to implement byte addresable
rather than word addressable arrays. Also many parralelization efforts on
these codes use C library routines to handle the message passing/load balancing
on parralel machines.

>                                                                      If
> we want to go faster by orders of magnitude then only better algorithms
> and/or faster hardware can do it for us; not compiler optimizations. But
> most importantly we need the right answer not the fastest answer.
> 

   I agree whole-heartedly with this. But what will happen will most likely
be evolution rather than revolution. As I have pointed out above, the evolution
is already happening.

-Regards

galen