Subject: CCL:OOP

From: Dan Severance <[email-masked]>
Date: Wed, 9 Feb 94 12:18:52 EST

?? writes (sorry):
> 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.

Paul Townsend replies:
> I find this point mildly hilarious ! Just yesterday I came across an Amber
> example where user in question had to increase an array parameter in order
> to perform a calculation. Time to edit and recompile was minutes.
> Increased execution time vs dynamic allocation (C etc ...) was probably a
> second at most. Fair trade ? I think not.
> 
      Hi,
      I am a postdoc in the lab of William Jorgensen here at Yale.

      The argument that only a second is saved assumes short run times.
   What you have to realize is that while not the rule, there are many
   of us to whom the CPU time required to do a project is days, weeks
   or even months of continuous running!  Even a 10% increase in
   program speed is negligible for a 1 hour program run, but means a
   savings of 6 days for a 2 month program run!  I'll gladly spend 3
   minutes recompiling to save 6 days.  We currently have 8 or 9 SGI
   machines that run BOSS and AMBER jobs 24 hours a day, 7 days a week,
   365 days a year.  Over a year, that 10% (or more) amounts to more
   than an extra month of CPU time available.

      Program speed, machine speed and functionality are all
   significant considerations to us, but a highly functional, less
   efficient code will tend to only be used in the specialized
   situations where it is essential, and not for anything else.  We
   have some other packages, one is commercial (written in C), with a
   very nice graphics interface.   The code is extremely slow, however,
   and we've never used it (or even considered it) for any research
   project.

      I'd love to have easy to use, object oriented code, but if we 
   have to sacrifice a great deal of speed, it'll not become our 
   software of choice.  We spend money buying new machines to get
   faster turn around and then work on even larger problems, we 
   aren't going to turn around and use slower code.   (And no, a 
   comparably priced IBM is slower for the money when running these 
   programs, so don't question why we use SGIs!)
   
      Dan Severance
      Yale University Chemistry Dept.

**** My opinions are my own :-) ****