Phil Austin wrote:
> Jeremy Howard writes:
>
> > * Compiling complex templates (as occur in expression templates) is slow,
> > when using optimisation. For example, with KAI, a simple addition of four
> > vectors with POOMA takes around 2 hours to compile with full optimisation on
> > a PII/366 Win2k.
>
> Am I wrong to live in hope that the export keyword will
> significantly improve this situation? I was disappointed to
> see that export is still not going to be supported in
> KCC 4.0
There are two main contributors to long compile times with C++ libraries
like POOMA. One is instantiation of class templates used by an application,
such as POOMA's Array and Engine types. The other is instantiation of
template types generated by expressions used in the code, followed by
intensive function inlining and optimization of the resultant code. Which
of these domainates depends heavily on the content of the application code.
The first problem can be addressed by pre-instantiation and compilation of
the template types most frequently used by applications (assuming this can
be determined). For instance, if I know I will be working with 2D Arrays
of doubles in my code, why not explicitly instantiate that type and compile
the instance into a library? Then I do not have to repeatedly compile that
instantiation every time I edit my application. The advantage of "export"
here, as I understand it, is that POOMA could export the implementation
of the class template Array as code pre-compiled into a library, and would
not have to supply the source code for the implementation. I'm not sure
if that would really impact the compile time issue though. (We do not
expect to see "export" supported in any C++ compiler anytime soon.) I am
oversimplifying a bit here, but basically explicit instantiation of library
types can be done by the library writer (or the user) to reduce the compile
burden on the application code itself.
The second problem cannot be addressed in this manner because one
cannot very easily spell out explicitly the template types that need to be
instantiated. As was noted, you get these weird complicated types that
represent subsets of the expression parse tree, and each expression
involving a different combination of operand types and operators will
create unique instantiations. You can play some games with carefully
placed parentheses in your expressions to reduce the number of distinct
subexpression types that are created. But in general, this is a limitation
of the expression template technique. My only suggestion here is to
isolate expressions into separate source code units as much as possible,
so that they are recompiled infrequently, only when the expression is
actually modified.
Regards, Julian C.
-- Julian C. Cummings Advanced Computing Laboratory Los Alamos National Laboratory (505) 667-6064 julianc@acl.lanl.gov--------------------- Object Oriented Numerics List -------------------------- * To subscribe/unsubscribe: use the handy web form at http://oonumerics.org/oon/ * If this doesn't work, please send a note to owner-oon-list@oonumerics.org
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:11 EST