Re: is C necessarily faster than C++

jdean@pysht.cs.washington.edu (Jeffrey Dean)
Tue, 9 May 1995 04:31:22 GMT

          From comp.compilers

Related articles
[13 earlier articles]
Re: is C necessarily faster than C++ urs@engineering.ucsb.edu (1995-04-28)
Re: is C necessarily faster than C++ quanstro@hp-demo1.minerva.bah.com (1995-04-28)
Re: is C necessarily faster than C++ beard@cs.ucdavis.edu (Patrick C. Beard) (1995-04-28)
is C necessarily faster than C++ ka@socrates.hr.att.com (1995-04-28)
Re: is C necessarily faster than C++ jplevyak@pink-panther.cs.uiuc.edu (1995-04-29)
Re: is C necessarily faster than C++ tmb@netcom.com (1995-04-29)
Re: is C necessarily faster than C++ jdean@pysht.cs.washington.edu (1995-05-09)
Re: is C necessarily faster than C++ calder@mumble.cs.Colorado.EDU (1995-05-09)
Re: is C necessarily faster than C++ schow@bnr.ca (stanley (s.t.h.) chow) (1995-05-09)
Re: is C necessarily faster than C++ mike@vlsivie.tuwien.ac.at (1995-05-04)
Re: is C necessarily faster than C++ bill@amber.ssd.hcsc.com (1995-05-16)
Re: is C necessarily faster than C++ itcp@praxis.co.uk (1995-06-23)
Re: is C necessarily faster than C++ jplevyak@violet-femmes.cs.uiuc.edu (1995-06-23)
[2 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: jdean@pysht.cs.washington.edu (Jeffrey Dean)
Keywords: C++, OOP, optimize, C
Organization: University of Washington
References: 95-04-202
Date: Tue, 9 May 1995 04:31:22 GMT

This thread is touching on a number of topics that we've looked at as
part of the Cecil project at the University of Washington (excuse the
blatant plug of our work :).


jplevyak@pink-panther.cs.uiuc.edu (John B. Plevyak) writes:
|> Virtual functions can be inlined through a number of techniques:
|>
|> Generally:
|>
|> -- Speculative Inlining (Prediction/Splitting): insert an inline test
|> for the 'most likely' class:
|>
|> if (x->class_id == CLASS_A) {
|> ... inline code x->bar() ...
|> } else x->bar()


One concern about inserting class predictions is that they can
potentially slow down the code, if the distribution of receiver
classes at a particular call site is either not heavily skewed towards
a few classes or if the most common class(es) varies significantly
across different program inputs or across different versions of the
program. Our group has done some studies of Cecil and C++ programs to
investigate the stability of receiver class distributions.
Fortunately, we found that class distributions tend to be extremely
stable, both across different program inputs and across different
versions of the program (reducing the need to profile the program
often) [1].


|> -- Specialiation (Customization/Cloning): replicate methods for
|> particular situations:


Customization is the approach of compiling a customized version of a
method for each class that inherits the method. For
statically-compiled systems, the code blowup from this specialization
strategy can be substantial, especially for large programs with lots
of methods and deep inheritance hierarchies. We've developed an
algorithm that combines information about where in the class hierarchy
methods are defined with dynamic gprof-style profile data to identify
specializations that provide the most benefit. This approach
substantially increases execution speed of Cecil programs, with code
space increases of only 5% to 10%, and the general technique could be used by
C++ implementations [2].


|> Unfortunately, these optimizations require that the compiler have
|> access to both the caller and the callee, as a minimun, and possibly
|> all the code in between (if global analysis is to be used to determine
|> the run time types of objects). It follows that separate compilation
|> of C++ programs can (fundamentally) inhibit these optimizatins.


In some environments, separate compilation is very important.
However, many other environments are equally well served by
incremental compilation, where the compiler is allowed to perform
cross-module optimizations, but keeps track of sufficient dependency
information to avoid recompiling modules unnecessarily. Our compiler
infrastructure performs whole-program optimizations by examining the
inheritance hierarchy of the whole program [3] yet still performs
incremental compilation, by maintaining fine-grained dependencies [4].


|> For background information see the work of the S{\sc elf} group
|> including the PhD thesis of Craig Chambers and that of Urs H\"{o}lzle.
|> and our own work on the Illinois Concert project:
|> http://www-csag.cs.uiuc.edu/


The papers referenced above and other papers on these topics can be
found on the Cecil project WWW page:


    http://www.cs.washington.edu/research/projects/cecil/www/cecil-home.html


(They can also be found via anonymous ftp from cs.washington.edu in
the directory /pub/chambers).


[1] "Profile-Guided Receiver Class Prediction", to appear in
OOPSLA'95, David Grove, Jeffrey Dean, Charlie Garrett, and Craig
Chambers


[2] "Selective Specialization for Object-Oriented Languages", to
appear in PLDI'95, Jeffrey Dean, Craig Chambers, and David Grove


[3] "Optimization of Object-Oriented Programs Using Static Class
Hierarchy Analysis", to appear in ECOOP'95, Jeffrey Dean, David Grove,
and Craig Chambers


[4] "A Framework for Selective Recompilation in the Presence of
Complex Intermodule Dependencies", ICSE'95, Craig Chambers, Jeffrey
Dean, and David Grove.


    -- Jeff


--------------------------------------------------------------------------
Jeffrey Dean (jdean@cs.washington.edu) Graduate Student, Cecil Project
Dept. of Computer Science & Engineering University of Washington
                      http://www.cs.washington.edu/homes/jdean/index.html
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.