Re: Templates in C++

davidm@flora.Rational.com (David Moore)
Tue, 16 May 1995 19:17:05 GMT

          From comp.compilers

Related articles
Templates in C++ jcohen@juniper.tc.cornell.edu (1995-05-11)
Re: Templates in C++ litsios@iis.ee.ethz.ch (1995-05-12)
Re: Templates in C++ jsgray@ix.netcom.com (1995-05-12)
Re: Templates in C++ shepherd@schubert.sbi.com (1995-05-12)
Re: Templates in C++ norman@flaubert.bellcore.com (1995-05-14)
Re: Templates in C++ davidm@flora.Rational.com (1995-05-16)
Re: Templates in C++ jgmorris@cs.cmu.edu (Greg Morrisett) (1995-05-17)
Re: Templates in C++ jplevyak@violet-femmes.cs.uiuc.edu (1995-05-17)
Re: Templates in C++ bill@amber.ssd.hcsc.com (1995-05-25)
Re: Templates in C++ kanze@gabi-soft.fr (1995-05-29)
Re: Templates in C++ mac@coos.dartmouth.edu (1995-06-23)
Re: Templates in C++ shankar@sgihub.corp.sgi.com (1995-06-25)
[2 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: davidm@flora.Rational.com (David Moore)
Keywords: C++, performance, Ada
Organization: Rational Software Corp
References: 95-05-081 95-05-096
Date: Tue, 16 May 1995 19:17:05 GMT

  shepherd@schubert.sbi.com (Marc Shepherd) writes:
> jcohen@juniper.tc.cornell.edu (Jeffrey Cohen) writes:
> >With all this discussion of the performance differences between
> >C and C++, I didn't see one reference to C++ templates. How does
> >this effect performance?
> [...]
> >[I was under the impression that the biggest practical problem with templates
> >is avoiding redundant instantiation when you have separately compiled modules.
> >Other than that, they act very much like macros, which don't present great
> >compiling problems. -John]
>
> The other challenge with templates is the "code bloat" that can
> result if many very similar templates are instantiated. (I guess you
> could call this "performance related," in that it can lead to
> larger-than-normal executables.)
>


In Ada, in which the equivalent of templates is generics, some compilers
allow you to specify a generic as either "shared" or "replicated". Typically,
you can specify this at the declaration site and then override it for a
particular instantiation of the generic.


Replicated generics are, of course, faster than shared code generics
in general. The largest hit will be when operations could have been
inlined in a replicated version, but not in a shared version. As
in some cases the operation will be a single machine instruction, this
overhead can be quite significant.


Ada 95 has a new capability of defining a generic with another
generic as a formal parameter. When such a generic is instantiated,
an instantiation of the formal generic must be provided as an
actual parameter. This may produce some opportunities for reducing the
overhead of shared generics.


The overhead can also be reduced by allowing procedures created
by instantiating a generic to participate in inlining in the same way
that ordinary procedures do. For example, in the case of a list, one
would inline many of the operations in any case, whether the list
was implemented as a list of voids, or as the instantiation of a
generic. When this is done, shared code generics can conceivably give
better performance in some cases than replicated generics because
cache coherence is promoted for the larger routines while no overhead
is incurred for the smaller..


The problem of code bloat is worse in C++ than in Ada for at least two
reasons.


First, templates sometimes get instantiated implicitly, so that the programmer
may not be aware that an overhead has been incurred. In Ada, each
instantiation must be called for, and programmers will try to avoid
multiple instantiations for a given set of actuals.


Secondly, there is no module concept in C++, so an instantiation in
a header file has no "home" module in which any generated code can
be placed. Instead, an instantiation in a header file will get
instantiated seperately in every file into which that header is
included, and co-operation from the linker is required to merge these.




















--


Post a followup to this message

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