[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [pooma-dev] Compile Time Problems and Pooma 2
|
From: |
Dave Nystrom |
|
Subject: |
RE: [pooma-dev] Compile Time Problems and Pooma 2 |
|
Date: |
Tue, 29 May 2001 11:53:16 -0600 (MDT) |
Hi Stephen,
Thanks for your reply.
Stephen Smith writes:
> I have a few comments/questions.
>
> When I looked at compile times on Nirvana, they were
> generally linearly related to the intermediate c file
> size (In K, not the number of lines). Do you know what
> the sizes of the intermediate files are? A lot of the time
Here are the b18 results with the extra info you requested. I decided to
record the size of the .int.c files in MBytes for obvious reasons:-).
b18 results: Irix 6.5, MipsPro 7.3.1.2m
---------------------------------------
Filename | # of .ii | # lines of | +K0 Compile | Line | Time |
Size In
| lines | int C code | Time | Ratio | Ratio |
MBytes
------------------------------------------------------------------------------------
assign_arg7_03.cc | 341 | 566783 | 7070.603 | 5.46 | 24.14 |
61.73
------------------------------------------------------------------------------------
assign_arg5_01.cc | 349 | 314395 | 3266.179 | 3.03 | 11.15 |
32.59
------------------------------------------------------------------------------------
assign_arg7_09.cc | 144 | 314070 | 2320.959 | 3.02 | 7.92 |
33.55
------------------------------------------------------------------------------------
assign_arg7_13.cc | 124 | 209043 | 1142.474 | 2.01 | 3.90 |
22.54
------------------------------------------------------------------------------------
assign_arg5_03.cc | 0 | 103832 | 292.872 | 1.00 | 1.00 |
10.66
------------------------------------------------------------------------------------
> is related to just writing the file to disk. Compile times
> are significantly faster if you checkout the repository
> on a local filesystem. (I used to use /scratch.) You would
> probably see significantly slower compile time on Linux if
> you compiled on directories mounted using NFS.
I read your later email so I know you picked up on the fact that I am using
/scratch on b18. Also, b18 was essentially idle so that I had a pretty
dedicated compile platform. The only stuff I was grabbing from an NFS disk
was the KCC headers and the system headers. I have actually installed KCC on
the scratch disk in the past and noticed about a 10% reduction in compile
time by having the KCC headers local. I've never copied the system headers
over to scratch but I thought about it once. Should not be hard but I
figured the performance increase would be comparable to making KCC local
i.e. about 10%. On our secure Pooma 1 code when I moved Pooma 1 and our
Blanca source code from NFS to the scratch disk, I reduced compile times by a
factor of 3. That was after we already had /tmp on scratch and all our build
products going to scratch.
> I'm not sure why you're instantiating View1 etc. instead of
> the functions that Blanca uses directly. For arrays, this would
> be op() and read(). For example:
>
> template View1<Array<2, double, Brick>, Interval<2> >::Type_t
> Array<2, double, Brick>::operator()(const Interval<2> &) const;
I am trying to make a custom Blanca instantiation library for Pooma 2
templates and to also explicitly instantiate all the templates that Blanca
uses, including STL templates and Blanca templates. The fundamental reason
for this tedious exercise is to significantly reduce the overall compile time
required to build Blanca software. There are two ways to get compile time
reductions. One is to instantiate Pooma 2 templates that we are using in a
separate Pooma2Instantiations library that only gets recompiled when we
update or change Pooma 2. Then, all of the Pooma 2 templates that would have
normally been assigned to Blanca translation units are now in this
instantiation library that only needs to be rebuilt on an infrequent basis
i.e. when we update Pooma 2. So, a tremendous amount of compilation work has
been pushed to a lower level. The second way to significantly reduce compile
times is to eliminate recompiles that the prelinker performs. But the way
this works is that you start reducing the number of templates that get
assigned to a translation unit by the prelinker but until you make that
number go to 0, you will still be recompiling the file. One problem with
relying on the prelinker is that you can't very easily control which
translation units it chooses to assign templates to and it tends to be pretty
democratic and assign some to all. Maybe we need a republican prelinker that
would assign all the templates to just a few:-). Anyway, the bottom line is
that I need to be able to explicitly instantiate any template that the
compiler can instantiate which when using EDG based compilers is via the
prelinker. The absolute only reason that I want to instantiate the
View1<...>::sv template is because when I analyse the .ii files for our
Blanca compiles I find that the compiler has found references to 1800+ of
these templates that if feels obliged to instantiate. I need to be able to
instantiate them myself so the prelinker does not put some in nearly every
translation unit and then feel obliged to recompile that translation unit.
> You can't instantiate the AltView classes because there is a
> circular dependency between the field and the view class that
> AltView is used to solve.
I realize this. I'm just pointing out in my previous email that Jeffrey's
fix unfortunately did not really solve the fundamental problem that I am
trying to solve. I can now instantiate the View1 class but now I have just
as many AltView1 templates that I cannot instantiate and the prelinker is
going to be very democratic about where it assigns them as well.
> Finally, what are the compile times for Debug? Probably a set of
The times that I reported were Debug compile times i.e. +K0 - at least for
the b18 stuff. The second experiment that I did was aimed at studying how
many lines of C code would be generated for different compile optimization
levels for just one of these global assign functions i.e. the one with the
longest template argument which would presumably be associated with the most
complex assignment expression that we were using or at least pretty close to
the most complex. So in the second experiment, I did +K0, +K1, +K2 and +K3
builds. For optimization levels of +K1 and higher, I included these options
as well. These were what my optimized builds of the Pooma 2 library were
adding on.
-DNOCHEETAHCTAssert -DNOCHEETAHRTAssert -DNOPAssert -DNOCTAssert \
--restrict --inline_keyword_space_time=10000.0
> compile options that don't inline and don't add the bounds checking
> code would give you much shorter compile times. Adding a non-expression
> template implementation would be a moderate chunk of work and may or may
> not improve compile times significantly. Compile times come from making
> the views, and building the expression. Compiling the expression evaluation
> is insignificant. Replacing expression templates could save you the
> compile time related to building the expression, but the cost of making
> the view objects may still be significant.
Hmmmmmmmmm. Well, I don't really understand what drives the compile times
for Pooma 2 based code very well. At the lowest level there seems a strong
correlation with the amount of intermediate C code that is generated whether
measured in lines or bytes. Also, when it comes to optimizing functions, I
am under the impression that the optimization process generally scales
quadratically or perhaps worse with the size of the function body. But I
have no idea why the intermediate C code to evaluate a single complex
expression should be measured in tens of thousands of lines of code even
though it is evaluating this expression in a parallel environment, etc. This
somehow does not seem reasonable to me but I claim ignorance and am perhaps
being naive. I would imagine that reductions could be made but I don't know
if this would involve trade offs and if so, what they would be. From my
position of ignorance about the details of Pooma 2, I worry that 1). the
design is not properly factored so that alot of the code for one global
assign function looks the same as that for another global assign function,
only the template parameters are a little different and 2). that functions
are being inlined that do not really need to be inlined for runtime
performance reasons. But again, I must emphasize my position of ignorance
because I just have not had time to study the details of Pooma 2 - spending
too much time trying to get manageable compile times.
Hope others will chime in with their evaluation of all this stuff. Thanks
again, Stephen, for your response. Let me know if I can provide additional
information.
--
Dave Nystrom email: address@hidden
LANL X-3 phone: 505-667-7913 fax: 505-665-3046
> Stephen
>
> -----Original Message-----
> From: Dave Nystrom [mailto:address@hidden
> Sent: Monday, May 28, 2001 2:47 PM
> To: pooma-dev
> Cc: Arch Robison; KCC Support; Dave Nystrom; John Hall; Jean Marshall;
> Don Marshall
> Subject: [pooma-dev] Compile Time Problems and Pooma 2
>
>
> Hi Guys,
>
> I wanted to share some results which I have accumulated over the last week
> or
> so regarding compile times and Pooma 2. Some of these results I find to be
> truly stunning in a negative sense. First, I spent most of last week trying
> to build a couple of versions of my Pooma2Instantiations library on the
> secure bluemountain b18 machine. I built a debug and an optimized version
> of
> the library using KCC-4.0d. I had the source code for Pooma 2 and the
> Pooma2Instantiations library located on the local scratch disk. I was doing
> a parallel using 16 processors including 16 processors for the parallel
> prelink phase. The timing results which I will be reporting were
> accumulated
> this last Friday when b18 was virtually idle except for my compiles. The
> stunning result is that I could build either a debug or optimized version of
> the library faster on my 2 year old 366 MHz Pentium 2 laptop with 384 MBytes
> of memory than I could on an idle b18 using 16 processors. I find this
> result to be truly stunning. The majority of the compile time, at least
> 90%,
> on b18 was spent in the backend C compiler. Here are some timings that I
> did
> on 5 files that were associated with instantiating the Pooma 2 global assign
> function on both b18 and my old laptop. The timing results are not totally
> comparable because the prelinker chooses to assign templates a little
> differently from one machine to the other because of doing a parallel
> compile
> on b18. These compiles were +K0 compiles using KCC-4.0d. Anyway, here they
> are:
>
> b18 results: Irix 6.5, MipsPro 7.3.1.2m
> ---------------------------------------
>
> Filename | # of .ii | # lines of | +K0 Compile | Line | Time
> | lines | int C code | Time | Ratio | Ratio
> --------------------------------------------------------------------------
> assign_arg7_03.cc | 341 | 566783 | 7070.603 | 5.46 | 24.14
> --------------------------------------------------------------------------
> assign_arg5_01.cc | 349 | 314395 | 3266.179 | 3.03 | 11.15
> --------------------------------------------------------------------------
> assign_arg7_09.cc | 144 | 314070 | 2320.959 | 3.02 | 7.92
> --------------------------------------------------------------------------
> assign_arg7_13.cc | 124 | 209043 | 1142.474 | 2.01 | 3.90
> --------------------------------------------------------------------------
> assign_arg5_03.cc | 0 | 103832 | 292.872 | 1.00 | 1.00
> --------------------------------------------------------------------------
>
>
> mutley results: RedHat 6.2
> --------------------------
>
> Filename | # of .ii | # lines of | +K0 Compile | Line | Time
> | lines | int C code | Time | Ratio | Ratio
> --------------------------------------------------------------------------
> assign_arg7_03.cc | 0 | 478303 | 467.63 | 3.63 | 2.84
> --------------------------------------------------------------------------
> assign_arg5_01.cc | 246 | 308959 | 428.92 | 2.28 | 2.61
> --------------------------------------------------------------------------
> assign_arg7_09.cc | 91 | 272079 | 360.49 | 2.01 | 2.19
> --------------------------------------------------------------------------
> assign_arg7_13.cc | 178 | 231415 | 254.78 | 1.71 | 1.55
> --------------------------------------------------------------------------
> assign_arg5_03.cc | 207 | 135366 | 164.39 | 1.00 | 1.00
> --------------------------------------------------------------------------
>
> It seems that on my linux laptop, gcc's compile time scales roughly linearly
> with the number of lines of intermediate C code. That does not seem to be
> the case for the SGI cc compiler. I computed these results using both the
> MipsPro 7.2.1 C compiler and the MipsPro 7.3.1.2m C compiler and the results
> were essentially identical for practical purposes.
>
> Another experiment which I did was to take the instantiation request for the
> assign function which had the longest template argument and put that in a
> separate file and do some testing on my linux laptop. The longest template
> argument was 1666 characters in length. Here are the results with and
> without exceptions enabled.
>
> With Exceptions:
> ----------------
>
> Case | # lines of | Compile | Optimization | # lines of int | Compile
> | int C code | Time | Level | C code - base | Time - base
> -------------------------------------------------------------------------
> 1 | 28804 | 33.34 | +K0 | 51 | 12.50
> -------------------------------------------------------------------------
> 2 | 18263 | 35.27 | +K1 | 37 | 12.33
> -------------------------------------------------------------------------
> 3 | 14451 | 62.21 | +K2 | 18 | 12.35
> -------------------------------------------------------------------------
> 4 | 15767 | 76.47 | +K3 | 18 | 12.30
> -------------------------------------------------------------------------
>
> Without Exceptions:
> -------------------
>
> Case | # lines of | Compile | Optimization | # lines of int | Compile
> | int C code | Time | Level | C code - base | Time - base
> -------------------------------------------------------------------------
> 1 | 26975 | 25.01 | +K0 | 41 | 12.47
> -------------------------------------------------------------------------
> 2 | 16288 | 31.08 | +K1 | 37 | 13.71
> -------------------------------------------------------------------------
> 3 | 12476 | 49.62 | +K2 | 18 | 12.32
> -------------------------------------------------------------------------
> 4 | 13037 | 57.00 | +K3 | 18 | 12.33
> -------------------------------------------------------------------------
>
> The results recorded in the "base" columns are results obtained when the
> template instantiation request is commented out and reflects the compile
> times and lines of intermediate C code for the case where only the included
> header files are being parsed. Care was taken to record the number of lines
> of intermediate C code before the prelinker phase. The prelinker phase
> determines that the explicit instantiation request for this single assign
> function triggers the need for an additional 292 templates and the lines of
> intermediate C code for these additional 292 templates nearly doubles the
> above numbers. It seems amazing that a single assign function would need
> between 14430 and 28750 lines of intermediate C code to represent it
> depending on the optimization level and that it would trigger the need for
> another 292 templates. Also, I don't think we have gotten to the level of
> complexity in the expressions for our Pooma 2 based code that we have in our
> Pooma 1 based code. In our Pooma 1 based code, I have seen expressions
> which
> generate template parameters over 2800 characters long.
>
> Here is another benchmark to compare the Pooma 2 base code and the Pooma 1
> based code. In the Pooma 1 based code, my instantiation library explicitly
> instantiated nearly every Pooma 1 template. The +K1 compilation of this
> instantiation library generated approximately 3.5 million lines of
> intermediate C code for the whole library and just under 1 million lines for
> the instantiation of all the global assign functions. There were about 1196
> of these global assign functions that were instantiated. In constrast, the
> Pooma 2 instantiation library instantiates 1282 global assign functions
> which
> generates 4711082 lines of intermediate C code. The complete Pooma 2
> instantiation library currently generates 5327932 lines of intermediate C
> code. However, there are still lots of Pooma 2 templates that are currently
> being instantiated by the prelinker in our Blanca code that need to be moved
> to the Pooma 2 instantiation library. So, it appears that there is alot
> more
> intermediate C code generated by KCC for our Pooma 2 code than for our Pooma
> 1 code. I'm not sure what to make of all this since to a certain degree I
> am
> comparing apples and oranges. But I think it does provide some indication
> of
> how Pooma 1 and Pooma 2 compare in regard to code generation which
> contributes to long compile times.
>
> Also, I tried out Jeffrey's fixes to allow instantiation of the View1 class
> and have some comments. It appears that I can now instantiate the View1
> class but now I find that I have about 1000 AltView1 templates that I am
> unable to instantiate. Perhaps we need a new AltAltView1 class:-). Well,
> seriously, this fix is not solving the root problem which I have which is
> that I need to be able to explicitly instantiate anything that the compiler
> is able to instantiate so that I don't have to depend on the prelinker
> recompiling files. Also, I tried the following template instantiation
> request which did not work.
>
> template const bool View1<Field<T1,T2,T3>,T4>::sv;
>
> KCC using --strict complained that I did not provide an implementation. So,
> I don't know what the problem is here. I don't know if the syntax is wrong
> or there is some bug in KCC. But I do know that the prelinker is capable of
> performing the instantiation of this member of the View1 class. I have this
> problem with other Pooma 2 classes such as the ElementProperties class. I
> wish I could get this problem solved because my compile times are at least
> twice as long as they would be if I were able to instantiate everything that
> the compiler is instantiating.
>
> I would like to know what the Pooma 2 team things about these results. I
> find them sobering and not something that I want to see publicized. Do you
> guys have any ideas about how to modify the relevant parts of Pooma 2 so
> that
> less intermediate C code gets generated by KCC? Are there tradeoffs here
> that you are aware of? Is this code generation problem related specifically
> to the expression template engine or are there other things involved here?
> I've been wondering lately if Pooma 2 was designed in a way that would make
> it easy to use some other expression template engine. I've also been
> wondering whether it would be possible to make expression templates a
> feature
> selectable at compile time. Then for debugging or development perhaps a
> more
> lightweight version of Pooma 2 could be used that would run like a dog but
> compile much faster and facilitate an effective and efficient development
> environment. Then building a high performance runtime version of our code
> could be banished to a batch script that was done only infrequently or by a
> very small group of people. Are things like this reasonable to contemplate
> with Pooma 2?
>
> Please let me know if you have any questions about the results I have
> presented in this email or if I can supply additional information. I plan
> to
> also send a copy of the current version of my Pooma 2 instantiation stuff so
> you guys can do any testing of your own that you want to do.
>
> --
> Dave Nystrom email: address@hidden
> LANL X-3 phone: 505-667-7913 fax: 505-665-3046
> <!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] Compile Time Problems and Pooma 2</TITLE>
> </HEAD>
> <BODY>
>
> <P><FONT SIZE=2>I have a few comments/questions.</FONT>
> </P>
>
> <P><FONT SIZE=2>When I looked at compile times on Nirvana, they were</FONT>
> <BR><FONT SIZE=2>generally linearly related to the intermediate c file</FONT>
> <BR><FONT SIZE=2>size (In K, not the number of lines). Do you know
> what</FONT>
> <BR><FONT SIZE=2>the sizes of the intermediate files are? A lot of the
> time</FONT>
> <BR><FONT SIZE=2>is related to just writing the file to disk. Compile
> times</FONT>
> <BR><FONT SIZE=2>are significantly faster if you checkout the
> repository</FONT>
> <BR><FONT SIZE=2>on a local filesystem. (I used to use /scratch.) You
> would</FONT>
> <BR><FONT SIZE=2>probably see significantly slower compile time on Linux
> if</FONT>
> <BR><FONT SIZE=2>you compiled on directories mounted using NFS.</FONT>
> </P>
>
> <P><FONT SIZE=2>I'm not sure why you're instantiating View1 etc. instead
> of</FONT>
> <BR><FONT SIZE=2>the functions that Blanca uses directly. For arrays,
> this would</FONT>
> <BR><FONT SIZE=2>be op() and read(). For example:</FONT>
> </P>
>
> <P><FONT SIZE=2>template View1<Array<2, double, Brick>,
> Interval<2> >::Type_t</FONT>
> <BR><FONT SIZE=2>Array<2, double, Brick>::operator()(const
> Interval<2> &) const;</FONT>
> </P>
>
> <P><FONT SIZE=2>You can't instantiate the AltView classes because there is
> a</FONT>
> <BR><FONT SIZE=2>circular dependency between the field and the view class
> that</FONT>
> <BR><FONT SIZE=2>AltView is used to solve.</FONT>
> </P>
>
> <P><FONT SIZE=2>Finally, what are the compile times for Debug?
> Probably a set of</FONT>
> <BR><FONT SIZE=2>compile options that don't inline and don't add the bounds
> checking</FONT>
> <BR><FONT SIZE=2>code would give you much shorter compile times.
> Adding a non-expression</FONT>
> <BR><FONT SIZE=2>template implementation would be a moderate chunk of work
> and may or may</FONT>
> <BR><FONT SIZE=2>not improve compile times significantly. Compile
> times come from making</FONT>
> <BR><FONT SIZE=2>the views, and building the expression. Compiling the
> expression evaluation</FONT>
> <BR><FONT SIZE=2>is insignificant. Replacing expression templates
> could save you the</FONT>
> <BR><FONT SIZE=2>compile time related to building the expression, but the
> cost of making</FONT>
> <BR><FONT SIZE=2>the view objects may still be significant.</FONT>
> </P>
>
> <P><FONT SIZE=2> Stephen</FONT>
> </P>
>
> <P><FONT SIZE=2>-----Original Message-----</FONT>
> <BR><FONT SIZE=2>From: Dave Nystrom [<A
> HREF="mailto:address@hidden";>mailto:address@hidden</A>]</FONT>
> <BR><FONT SIZE=2>Sent: Monday, May 28, 2001 2:47 PM</FONT>
> <BR><FONT SIZE=2>To: pooma-dev</FONT>
> <BR><FONT SIZE=2>Cc: Arch Robison; KCC Support; Dave Nystrom; John Hall;
> Jean Marshall;</FONT>
> <BR><FONT SIZE=2>Don Marshall</FONT>
> <BR><FONT SIZE=2>Subject: [pooma-dev] Compile Time Problems and Pooma
> 2</FONT>
> </P>
> <BR>
>
> <P><FONT SIZE=2>Hi Guys,</FONT>
> </P>
>
> <P><FONT SIZE=2>I wanted to share some results which I have accumulated over
> the last week or </FONT>
> <BR><FONT SIZE=2>so regarding compile times and Pooma 2. Some of these
> results I find to be</FONT>
> <BR><FONT SIZE=2>truly stunning in a negative sense. First, I spent
> most of last week trying</FONT>
> <BR><FONT SIZE=2>to build a couple of versions of my Pooma2Instantiations
> library on the</FONT>
> <BR><FONT SIZE=2>secure bluemountain b18 machine. I built a debug and
> an optimized version of </FONT>
> <BR><FONT SIZE=2>the library using KCC-4.0d. I had the source code for
> Pooma 2 and the</FONT>
> <BR><FONT SIZE=2>Pooma2Instantiations library located on the local scratch
> disk. I was doing</FONT>
> <BR><FONT SIZE=2>a parallel using 16 processors including 16 processors for
> the parallel</FONT>
> <BR><FONT SIZE=2>prelink phase. The timing results which I will be
> reporting were accumulated </FONT>
> <BR><FONT SIZE=2>this last Friday when b18 was virtually idle except for my
> compiles. The</FONT>
> <BR><FONT SIZE=2>stunning result is that I could build either a debug or
> optimized version of</FONT>
> <BR><FONT SIZE=2>the library faster on my 2 year old 366 MHz Pentium 2
> laptop with 384 MBytes</FONT>
> <BR><FONT SIZE=2>of memory than I could on an idle b18 using 16
> processors. I find this</FONT>
> <BR><FONT SIZE=2>result to be truly stunning. The majority of the
> compile time, at least 90%, </FONT>
> <BR><FONT SIZE=2>on b18 was spent in the backend C compiler. Here are
> some timings that I did </FONT>
> <BR><FONT SIZE=2>on 5 files that were associated with instantiating the
> Pooma 2 global assign</FONT>
> <BR><FONT SIZE=2>function on both b18 and my old laptop. The timing
> results are not totally</FONT>
> <BR><FONT SIZE=2>comparable because the prelinker chooses to assign
> templates a little</FONT>
> <BR><FONT SIZE=2>differently from one machine to the other because of doing
> a parallel compile </FONT>
> <BR><FONT SIZE=2>on b18. These compiles were +K0 compiles using
> KCC-4.0d. Anyway, here they</FONT>
> <BR><FONT SIZE=2>are:</FONT>
> </P>
>
> <P><FONT SIZE=2>b18 results: Irix 6.5, MipsPro 7.3.1.2m</FONT>
> <BR><FONT SIZE=2>---------------------------------------</FONT>
> </P>
>
> <P><FONT
> SIZE=2>Filename
> | # of .ii | # lines of | +K0 Compile | Line | Time</FONT>
> <BR><FONT
> SIZE=2>
> | lines | int C code |
> Time | Ratio | Ratio</FONT>
> <BR><FONT
> SIZE=2>--------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2>assign_arg7_03.cc | 341
> | 566783 | 7070.603 | 5.46
> | 24.14</FONT>
> <BR><FONT
> SIZE=2>--------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2>assign_arg5_01.cc | 349
> | 314395 | 3266.179 | 3.03
> | 11.15</FONT>
> <BR><FONT
> SIZE=2>--------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2>assign_arg7_09.cc | 144
> | 314070 | 2320.959 | 3.02
> | 7.92</FONT>
> <BR><FONT
> SIZE=2>--------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2>assign_arg7_13.cc | 124
> | 209043 | 1142.474 | 2.01
> | 3.90</FONT>
> <BR><FONT
> SIZE=2>--------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2>assign_arg5_03.cc |
> 0 | 103832 |
> 292.872 | 1.00 | 1.00</FONT>
> <BR><FONT
> SIZE=2>--------------------------------------------------------------------------</FONT>
> </P>
> <BR>
>
> <P><FONT SIZE=2>mutley results: RedHat 6.2</FONT>
> <BR><FONT SIZE=2>--------------------------</FONT>
> </P>
>
> <P><FONT
> SIZE=2>Filename
> | # of .ii | # lines of | +K0 Compile | Line | Time</FONT>
> <BR><FONT
> SIZE=2>
> | lines | int C code |
> Time | Ratio | Ratio</FONT>
> <BR><FONT
> SIZE=2>--------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2>assign_arg7_03.cc |
> 0 | 478303 |
> 467.63 | 3.63 | 2.84</FONT>
> <BR><FONT
> SIZE=2>--------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2>assign_arg5_01.cc | 246
> | 308959 | 428.92
> | 2.28 | 2.61</FONT>
> <BR><FONT
> SIZE=2>--------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2>assign_arg7_09.cc |
> 91 | 272079 |
> 360.49 | 2.01 | 2.19</FONT>
> <BR><FONT
> SIZE=2>--------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2>assign_arg7_13.cc | 178
> | 231415 | 254.78
> | 1.71 | 1.55</FONT>
> <BR><FONT
> SIZE=2>--------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2>assign_arg5_03.cc | 207
> | 135366 | 164.39
> | 1.00 | 1.00</FONT>
> <BR><FONT
> SIZE=2>--------------------------------------------------------------------------</FONT>
> </P>
>
> <P><FONT SIZE=2>It seems that on my linux laptop, gcc's compile time scales
> roughly linearly</FONT>
> <BR><FONT SIZE=2>with the number of lines of intermediate C code. That
> does not seem to be</FONT>
> <BR><FONT SIZE=2>the case for the SGI cc compiler. I computed these
> results using both the</FONT>
> <BR><FONT SIZE=2>MipsPro 7.2.1 C compiler and the MipsPro 7.3.1.2m C
> compiler and the results</FONT>
> <BR><FONT SIZE=2>were essentially identical for practical purposes.</FONT>
> </P>
>
> <P><FONT SIZE=2>Another experiment which I did was to take the instantiation
> request for the</FONT>
> <BR><FONT SIZE=2>assign function which had the longest template argument and
> put that in a</FONT>
> <BR><FONT SIZE=2>separate file and do some testing on my linux laptop.
> The longest template</FONT>
> <BR><FONT SIZE=2>argument was 1666 characters in length. Here are the
> results with and</FONT>
> <BR><FONT SIZE=2>without exceptions enabled.</FONT>
> </P>
>
> <P><FONT SIZE=2>With Exceptions:</FONT>
> <BR><FONT SIZE=2>----------------</FONT>
> </P>
>
> <P><FONT SIZE=2>Case | # lines of | Compile | Optimization | # lines of int
> | Compile</FONT>
> <BR><FONT SIZE=2> | int C code |
> Time | Level | C code
> - base | Time - base</FONT>
> <BR><FONT
> SIZE=2>-------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2> 1 | 28804
> | 33.34 |
> +K0 |
> 51 | 12.50</FONT>
> <BR><FONT
> SIZE=2>-------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2> 2 | 18263
> | 35.27 |
> +K1 |
> 37 | 12.33</FONT>
> <BR><FONT
> SIZE=2>-------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2> 3 | 14451
> | 62.21 |
> +K2 |
> 18 | 12.35</FONT>
> <BR><FONT
> SIZE=2>-------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2> 4 | 15767
> | 76.47 |
> +K3 |
> 18 | 12.30</FONT>
> <BR><FONT
> SIZE=2>-------------------------------------------------------------------------</FONT>
> </P>
>
> <P><FONT SIZE=2>Without Exceptions:</FONT>
> <BR><FONT SIZE=2>-------------------</FONT>
> </P>
>
> <P><FONT SIZE=2>Case | # lines of | Compile | Optimization | # lines of int
> | Compile</FONT>
> <BR><FONT SIZE=2> | int C code |
> Time | Level | C code
> - base | Time - base</FONT>
> <BR><FONT
> SIZE=2>-------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2> 1 | 26975
> | 25.01 |
> +K0 |
> 41 | 12.47</FONT>
> <BR><FONT
> SIZE=2>-------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2> 2 | 16288
> | 31.08 |
> +K1 |
> 37 | 13.71</FONT>
> <BR><FONT
> SIZE=2>-------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2> 3 | 12476
> | 49.62 |
> +K2 |
> 18 | 12.32</FONT>
> <BR><FONT
> SIZE=2>-------------------------------------------------------------------------</FONT>
> <BR><FONT SIZE=2> 4 | 13037
> | 57.00 |
> +K3 |
> 18 | 12.33</FONT>
> <BR><FONT
> SIZE=2>-------------------------------------------------------------------------</FONT>
> </P>
>
> <P><FONT SIZE=2>The results recorded in the "base" columns are
> results obtained when the</FONT>
> <BR><FONT SIZE=2>template instantiation request is commented out and
> reflects the compile</FONT>
> <BR><FONT SIZE=2>times and lines of intermediate C code for the case where
> only the included</FONT>
> <BR><FONT SIZE=2>header files are being parsed. Care was taken to
> record the number of lines</FONT>
> <BR><FONT SIZE=2>of intermediate C code before the prelinker phase.
> The prelinker phase</FONT>
> <BR><FONT SIZE=2>determines that the explicit instantiation request for this
> single assign</FONT>
> <BR><FONT SIZE=2>function triggers the need for an additional 292 templates
> and the lines of</FONT>
> <BR><FONT SIZE=2>intermediate C code for these additional 292 templates
> nearly doubles the</FONT>
> <BR><FONT SIZE=2>above numbers. It seems amazing that a single assign
> function would need</FONT>
> <BR><FONT SIZE=2>between 14430 and 28750 lines of intermediate C code to
> represent it</FONT>
> <BR><FONT SIZE=2>depending on the optimization level and that it would
> trigger the need for</FONT>
> <BR><FONT SIZE=2>another 292 templates. Also, I don't think we have
> gotten to the level of</FONT>
> <BR><FONT SIZE=2>complexity in the expressions for our Pooma 2 based code
> that we have in our</FONT>
> <BR><FONT SIZE=2>Pooma 1 based code. In our Pooma 1 based code, I have
> seen expressions which </FONT>
> <BR><FONT SIZE=2>generate template parameters over 2800 characters
> long.</FONT>
> </P>
>
> <P><FONT SIZE=2>Here is another benchmark to compare the Pooma 2 base code
> and the Pooma 1</FONT>
> <BR><FONT SIZE=2>based code. In the Pooma 1 based code, my
> instantiation library explicitly</FONT>
> <BR><FONT SIZE=2>instantiated nearly every Pooma 1 template. The +K1
> compilation of this</FONT>
> <BR><FONT SIZE=2>instantiation library generated approximately 3.5 million
> lines of</FONT>
> <BR><FONT SIZE=2>intermediate C code for the whole library and just under 1
> million lines for</FONT>
> <BR><FONT SIZE=2>the instantiation of all the global assign functions.
> There were about 1196</FONT>
> <BR><FONT SIZE=2>of these global assign functions that were
> instantiated. In constrast, the</FONT>
> <BR><FONT SIZE=2>Pooma 2 instantiation library instantiates 1282 global
> assign functions which </FONT>
> <BR><FONT SIZE=2>generates 4711082 lines of intermediate C code. The
> complete Pooma 2</FONT>
> <BR><FONT SIZE=2>instantiation library currently generates 5327932 lines of
> intermediate C</FONT>
> <BR><FONT SIZE=2>code. However, there are still lots of Pooma 2
> templates that are currently</FONT>
> <BR><FONT SIZE=2>being instantiated by the prelinker in our Blanca code that
> need to be moved</FONT>
> <BR><FONT SIZE=2>to the Pooma 2 instantiation library. So, it appears
> that there is alot more </FONT>
> <BR><FONT SIZE=2>intermediate C code generated by KCC for our Pooma 2 code
> than for our Pooma</FONT>
> <BR><FONT SIZE=2>1 code. I'm not sure what to make of all this since
> to a certain degree I am </FONT>
> <BR><FONT SIZE=2>comparing apples and oranges. But I think it does
> provide some indication of </FONT>
> <BR><FONT SIZE=2>how Pooma 1 and Pooma 2 compare in regard to code
> generation which</FONT>
> <BR><FONT SIZE=2>contributes to long compile times.</FONT>
> </P>
>
> <P><FONT SIZE=2>Also, I tried out Jeffrey's fixes to allow instantiation of
> the View1 class</FONT>
> <BR><FONT SIZE=2>and have some comments. It appears that I can now
> instantiate the View1</FONT>
> <BR><FONT SIZE=2>class but now I find that I have about 1000 AltView1
> templates that I am</FONT>
> <BR><FONT SIZE=2>unable to instantiate. Perhaps we need a new
> AltAltView1 class:-). Well,</FONT>
> <BR><FONT SIZE=2>seriously, this fix is not solving the root problem which I
> have which is</FONT>
> <BR><FONT SIZE=2>that I need to be able to explicitly instantiate anything
> that the compiler</FONT>
> <BR><FONT SIZE=2>is able to instantiate so that I don't have to depend on
> the prelinker</FONT>
> <BR><FONT SIZE=2>recompiling files. Also, I tried the following
> template instantiation</FONT>
> <BR><FONT SIZE=2>request which did not work.</FONT>
> </P>
>
> <P> <FONT SIZE=2>template const
> bool View1<Field<T1,T2,T3>,T4>::sv;</FONT>
> </P>
>
> <P><FONT SIZE=2>KCC using --strict complained that I did not provide an
> implementation. So,</FONT>
> <BR><FONT SIZE=2>I don't know what the problem is here. I don't know
> if the syntax is wrong</FONT>
> <BR><FONT SIZE=2>or there is some bug in KCC. But I do know that the
> prelinker is capable of</FONT>
> <BR><FONT SIZE=2>performing the instantiation of this member of the View1
> class. I have this</FONT>
> <BR><FONT SIZE=2>problem with other Pooma 2 classes such as the
> ElementProperties class. I</FONT>
> <BR><FONT SIZE=2>wish I could get this problem solved because my compile
> times are at least</FONT>
> <BR><FONT SIZE=2>twice as long as they would be if I were able to
> instantiate everything that</FONT>
> <BR><FONT SIZE=2>the compiler is instantiating.</FONT>
> </P>
>
> <P><FONT SIZE=2>I would like to know what the Pooma 2 team things about
> these results. I</FONT>
> <BR><FONT SIZE=2>find them sobering and not something that I want to see
> publicized. Do you</FONT>
> <BR><FONT SIZE=2>guys have any ideas about how to modify the relevant parts
> of Pooma 2 so that </FONT>
> <BR><FONT SIZE=2>less intermediate C code gets generated by KCC? Are
> there tradeoffs here</FONT>
> <BR><FONT SIZE=2>that you are aware of? Is this code generation
> problem related specifically</FONT>
> <BR><FONT SIZE=2>to the expression template engine or are there other things
> involved here?</FONT>
> <BR><FONT SIZE=2>I've been wondering lately if Pooma 2 was designed in a way
> that would make</FONT>
> <BR><FONT SIZE=2>it easy to use some other expression template engine.
> I've also been</FONT>
> <BR><FONT SIZE=2>wondering whether it would be possible to make expression
> templates a feature </FONT>
> <BR><FONT SIZE=2>selectable at compile time. Then for debugging or
> development perhaps a more </FONT>
> <BR><FONT SIZE=2>lightweight version of Pooma 2 could be used that would run
> like a dog but</FONT>
> <BR><FONT SIZE=2>compile much faster and facilitate an effective and
> efficient development</FONT>
> <BR><FONT SIZE=2>environment. Then building a high performance runtime
> version of our code</FONT>
> <BR><FONT SIZE=2>could be banished to a batch script that was done only
> infrequently or by a</FONT>
> <BR><FONT SIZE=2>very small group of people. Are things like this
> reasonable to contemplate</FONT>
> <BR><FONT SIZE=2>with Pooma 2?</FONT>
> </P>
>
> <P><FONT SIZE=2>Please let me know if you have any questions about the
> results I have</FONT>
> <BR><FONT SIZE=2>presented in this email or if I can supply additional
> information. I plan to </FONT>
> <BR><FONT SIZE=2>also send a copy of the current version of my Pooma 2
> instantiation stuff so</FONT>
> <BR><FONT SIZE=2>you guys can do any testing of your own that you want to
> do.</FONT>
> </P>
>
> <P><FONT SIZE=2>-- </FONT>
> <BR><FONT SIZE=2>Dave Nystrom
>
> email: address@hidden</FONT>
> <BR><FONT SIZE=2>LANL X-3
>
> phone:
> 505-667-7913 fax: 505-665-3046</FONT>
> </P>
>
> </BODY>
> </HTML>
- RE: [pooma-dev] Compile Time Problems and Pooma 2, Stephen Smith, 2001/05/28
- RE: [pooma-dev] Compile Time Problems and Pooma 2,
Dave Nystrom <=
- Re: [pooma-dev] Compile Time Problems and Pooma 2, Scott Haney, 2001/05/29
- Message not available
- Re: [pooma-dev] Compile Time Problems and Pooma 2, Dave Nystrom, 2001/05/29
- Re: [pooma-dev] Compile Time Problems and Pooma 2, Scott Haney, 2001/05/29
- Message not available
- Re: [pooma-dev] Compile Time Problems and Pooma 2, Dave Nystrom, 2001/05/29
- Re: [pooma-dev] Compile Time Problems and Pooma 2, Scott Haney, 2001/05/30
- Message not available
- Re: [pooma-dev] Compile Time Problems and Pooma 2, Dave Nystrom, 2001/05/30
- Message not available
- Re: [pooma-dev] Compile Time Problems and Pooma 2, Dave Nystrom, 2001/05/30