Subject: C++ performance tips summary

From: Richard Gillilan <[email-masked]>
Date: Tue, 26 Oct 1999 09:00:12 -0400

Now that the dust has cleared, here is a brief 
summary of the C++ vs Fortran discussion plus 
list of performance improvement suggestions.
Thanks to all who contributed! 

First, a few comments of my own. Arch Robison's 
article in Computers in Physics (vol 10, pp458-462 1996)
"C++ Gets Faster for Scientific Computing", though a little 
outdated by now, is well worth looking at. You can find the 
text online at the KAI web site:
  
     www.kai.com/publications/comp_phys/_index.html

In a private email to me, Arch also suggested looking at a recent
tutorial on the restrict keyword for C/C++:

     www.cuj.com/archive/1707/feature.html

Also, the October 99 issue of Dr. Dobb's Journal contains
a couple articles of interest:

  "Improving C++ Program Performance" (S. Lippman) and

  "PETE: The Portable Expression Template Engine"
  (Haney, Crotinger, Karmesin and Smith)

The best paper I've seen so far was suggested by Oliver Kohlbacher:

"Will C++ be faster than Fortran?" by Veldhizen and Jernigan
(downloadable at www.acl.lanl.gov/iscope97/agenda.htm)

The authors give some real-world examples where
C++ is as fast or faster than Fortran. They also list
reasons why C++ has been slower in the past and give
some features of the language that may allow it to be
faster in the future.  

Some advanced template-based frameworks for creating efficient 
code exist (Pooma, Blitz)... see the article above on PETE.
I haven't investigated these enough to comment, but they look
interesting. There do seem to be some simple coding practices 
worth trying. Here they are:

(my appologies for omitting some of the C++ vs Fortran discussion, but I
 wanted to stick to coding suggestions)

First, part of my original post:
----- 

Richard Gillilan writes:
>
>         o use ordinary C for heavy numerical tasks (simple constructs)
>         o use in-lining for critical functions
>         o avoid virtual functions (runtime function lookups)

I'll add these points from a private discussion with Dave Scheider here at the CTC:

          o put more code into the .h files so the compiler has more information
          o check to make sure functions do get inlined by the compiler using "nm"
          o avoid pointers in inner loops
          o encapsulate closely-related data in objects to improve memory access
            (the overhead of a function call may, in some situations, be offset 
             by the data localization achieved).
>
>I have found these to be VERY important.
>If you have additional guidlines, I would love to collect and summarize
>for the list. 
>
>
>(*) International Journal of Supercomputer Applications and High
>Performance
>    Computing Vol 10, No 4 Winter 1996 pp251-268
>
------------------------------------------------
Dear Richard,

Your suggested guidelines above all seem very good to me.  If you summarize
the CCL discussion on this efficiency issue, I would also note that, in
addition to the contribution of language constructs to code efficiency and
speed, the quality of the compiler is also vital.  For some commercial
systems, for example, Fortran compilers are (or, at least, used to be)
carefully optimized.  Hence, equally well-written C and Fortran codes 
(whatever that means) could behave with rather different speed/efficiency on
such systems.  On others (e.g., GNU systems), the difference between 
optimized Fortran and C (and C++) code is negligible since these use the 
same underlying compiler.  Users may want to keep this in mind when making
benchmark code comparisons.

Just my opinion.  I very much hope this line of discussion on CCL doesn't
degenerate into a C vs. Fortran holy war.

Take care,
-Daniel

-- 
T. Daniel Crawford, Ph.D.                Institute for Theoretical Chemistry

--------------------------------------------------------------

According to my experiences 30% seems to be an average value if you take a bit 
of care. Thoroughly optimized code can even be faster.
There is a paper by Veldhuizen and Jernigan ("Will C++ be faster than 
fortran", ISCOPE'97, extended abstract) that states that C++ might even be 
faster.
I can only recommend this paper and the stuff related to their Blitz++ library.

> The paper also gives a few guidelines: 
> 
>          o use ordinary C for heavy numerical tasks (simple constructs)
>          o use in-lining for critical functions
>          o avoid virtual functions (runtime function lookups)
I would add the following rules:
    o  use templates and template specialization. Although template code
       takes a long time to compile, it is very fast
    o  virtual function can often be replaced using templates
    o  use compact data structures to increase the locality of your code.
       Data encapsulation can also increases locality.
    o  use the better algorithms and data structures
        - C++ is much better suited to implement
       more sophisticated algorithms and data structures than FORTRAN and many 
       algorithms are already available in the libraries

Regards,
  Oliver

 Oliver Kohlbacher

-----------------------------------

Also pretty important for C++ optimization:
    o  use references (the "&" operator) in parameter lists
    o  make liberal use of the "const" keyword, as in:
            const memberFunction(const Classname &class, int i) const { ... }

--grg

-----------------------------------

These are good points especially the in-lining point on a heavily used
function call.   There is
however no guarantee that the compiler will in-line a function even if
it is declared to be in line.

If you have large arrays in your classes, and the data in them will be
the same for every instantiation of the class then make them static.  
-- 
**************
Jerry Perlstein

-------------------------------------

Richard Gillilan 
Cornell Theory Center