[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [pooma-dev] CompressibleBrickView's makeOwnCopy
|
From: |
Dave Nystrom |
|
Subject: |
RE: [pooma-dev] CompressibleBrickView's makeOwnCopy |
|
Date: |
Tue, 15 May 2001 15:04:22 -0600 (MDT) |
I'd just like to make it clear that I am not trying to instantiate the View1
class. Instead, I am only trying to explicitly instantiate what the
prelinker does which is:
View1<Field<T1, T2, T3>, T4>::sv
For our source code base, the prelinker discovers 1800-2000 combinations of
these template parameters. Also, on a source code base like ours, to get a
significant reduction in compile time through explicit instantiation, you
have to reduce the number of translation units that the prelinker is
recompiling. If the prelinker chooses to assign even one template to a given
translation unit, it will be recompiled. So, it takes some tedious work to
benefit from explicit instantiation on a source code base like ours but it
does pay off based on my experience with doing this on the r1 version of our
code.
I'm not totally sure just what compilers do regarding template instantiation
of non-inline functions. I've communicated with Arch Robison some about this
regarding KCC. I think this is what happens with KCC. If you are doing a
debug compile then nothing is inlined but every function that would have been
inlined is given internal linkage in any translation unit which references
it. But I'm not sure what this implies if you explicitly instantiate a class
containing these methods. Maybe Mark could comment on this - or maybe every
compiler has there own solution.
Dave
James Crotinger writes:
>
> The change looks fine.
>
> I'm generally against leaving functions in with { PAssert(false); } as their
> bodies. To me this indicates that we don't have the abstractions right. If
> preinstantiation were a requirement I might feel differently, but I don't
> think preinstantiation of Field probably buys you all that much. Indeed,
> there is no Field.cpp, so everything in Field is inline, so there is nothing
> to preinstantiate.
>
> Of course, this is also true for View1 - what exactly happens when you
> "preinstantiate" a class that has no non-inline functions? Doesn't the
> compiler still have to compile these functions in every file that uses them?
> I'm confused.
>
> Jim
>
> > -----Original Message-----
>
> > OK to commit the following patch to eliminate CompressibleBrickView's
> > makeOwnCopy()? Will the resulting code still solve Dave Nystrom's
> > makeOwnCopy() problem?
> >
> > 2001-05-15 Jeffrey D. Oldham <address@hidden>
> >
> > * Engine/CompressibleBrick.cpp
> > (Engine<Dim,T,CompressibleBrickView>::makeOwnCopy()):
> > Remove this
> > incorrectly introduced function.
> > * Engine/CompressibleBrick.h
> > (Engine<Dim,T,CompressibleBrickView>::makeOwnCopy()): Likewise.
> >
> > Tested on sequential Linux gcc 3.0 by compiling library
> > Approved by ???Jim Crotinger???
> >
> > Thanks,
> > Jeffrey D. Oldham
> > address@hidden
> >
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
> <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
> <TITLE>RE: [pooma-dev] CompressibleBrickView's makeOwnCopy</TITLE>
> </HEAD>
> <BODY>
> <BR>
>
> <P><FONT SIZE=2>The change looks fine. </FONT>
> </P>
>
> <P><FONT SIZE=2>I'm generally against leaving functions in with {
> PAssert(false); } as their bodies. To me this indicates that we don't have
> the abstractions right. If preinstantiation were a requirement I might feel
> differently, but I don't think preinstantiation of Field probably buys you
> all that much. Indeed, there is no Field.cpp, so everything in Field is
> inline, so there is nothing to preinstantiate. </FONT></P>
>
> <P><FONT SIZE=2>Of course, this is also true for View1 - what exactly
> happens when you "preinstantiate" a class that has no non-inline
> functions? Doesn't the compiler still have to compile these functions in
> every file that uses them? I'm confused. </FONT></P>
>
> <P> <FONT SIZE=2>Jim</FONT>
> </P>
>
> <P><FONT SIZE=2>> -----Original Message-----</FONT>
> </P>
>
> <P><FONT SIZE=2>> OK to commit the following patch to eliminate
> CompressibleBrickView's</FONT>
> <BR><FONT SIZE=2>> makeOwnCopy()? Will the resulting code still
> solve Dave Nystrom's</FONT>
> <BR><FONT SIZE=2>> makeOwnCopy() problem?</FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> 2001-05-15 Jeffrey D. Oldham
> <address@hidden></FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> *
> Engine/CompressibleBrick.cpp</FONT>
> <BR><FONT SIZE=2>>
> (Engine<Dim,T,CompressibleBrickView>::makeOwnCopy()): </FONT>
> <BR><FONT SIZE=2>> Remove this</FONT>
> <BR><FONT SIZE=2>> incorrectly introduced
> function.</FONT>
> <BR><FONT SIZE=2>> *
> Engine/CompressibleBrick.h</FONT>
> <BR><FONT SIZE=2>>
> (Engine<Dim,T,CompressibleBrickView>::makeOwnCopy()): Likewise.</FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> Tested on sequential Linux gcc
> 3.0 by compiling library</FONT>
> <BR><FONT SIZE=2>> Approved by ???Jim Crotinger???</FONT>
> <BR><FONT SIZE=2>> </FONT>
> <BR><FONT SIZE=2>> Thanks,</FONT>
> <BR><FONT SIZE=2>> Jeffrey D. Oldham</FONT>
> <BR><FONT SIZE=2>> address@hidden</FONT>
> <BR><FONT SIZE=2>> </FONT>
> </P>
>
> </BODY>
> </HTML>
--
Dave Nystrom email: address@hidden
LANL X-3 phone: 505-667-7913 fax: 505-665-3046