Re: Metaprogramming: Tool or toy? Case study: A law based test automaton
On Jun 12, 4:36 am, Joachim Faulhaber <afo...@googlemail.com> wrote:
[...]
The basic class template 'Law' needs polymorphic
typelists for input and output variables in order to
be really general:
template <typename InputTypes, typename OutputTypes>
class Law
{
public:
typedef typename Loki::tuple<InputTypes> input_tuple;
typedef typename Loki::tuple<OutputTypes> output_tuple;
public:
virtual ~Law(){}
virtual bool holds()=0;
...
}
Now we can define e.g. a general commutativity law that
can be instantiated for all kinds of types [...]
template <typename Type,
template<class>class BinaryOp = op_plus>
class Commutativity:
public Law<LOKI_TYPELIST_2(Type,Type),
LOKI_TYPELIST_2(Type,Type)>
{/* a+b==b+a; */...}
[...]
But now come the downsides :(
[...] With the number of laws and instance types
the compile time also grew nastily.
[...] The problem is that the slope of the function is much to steep
for vc8 and even worse for gcc. Even with the faster vc8 we spend
about 1.8 seconds compile time and 9 kBytes program size for
every law instance. Even the program speed that should be a
constant function suffers from the generated code especially with
gcc.
[...]
Any ideas how to tackle these compile time and code bloat problems
are highly apperciated.
I (ab)use metaprogramming a lot, both for heterogeneous fixed size
containers (tuples) and for polymorphic function object result type
computations (i.e. to implement the tr1::result_of protocol). I have
seen a marked increase in compile time, but so far I have been able to
keep it under control.
A couple of comments/hints:
1) do you really need to use virtual dispatch? I think that the huge
code bloat might be caused by the large amount of (often not
inlineable) virtual methods. This might be also cause the runtime
performance hit.
Can't you use compile-time polymorphic dispatch using the Curiously
Recurring Template Pattern:
template <typename InputTypes, typename OutputTypes, typename Derived>
class Law
{
public:
typedef typename Loki::tuple<InputTypes> input_tuple;
typedef typename Loki::tuple<OutputTypes> output_tuple;
public:
bool holds() {
static_cast<Derived*>(this)->holds();
}
...
}
template <typename Type,
template<class>class BinaryOp = op_plus, Commutativity<Type,
BinaryOp> >
class Commutativity:
public Law<LOKI_TYPELIST_2(Type,Type),
LOKI_TYPELIST_2(Type,Type)>
{/* a+b==b+a; */...}
In this case 'holds' is always inlineable and common code can be
easily factored out by the compiler. A virtual function is much harder
to optimize/eliminate.
Not sure if this is applicable to your case, but I suspect so.
2) You could try to use boost::fusion and boost::mpl instead of Loki.
MPL and fusion have lots of optimizations to reduce compile time (like
type list unrolling, O(1) access to vectors, and careful control on
the number of template instantiations).
I'm not sure, but think that Loki has been written to be readable
(i.e. a teaching/proof of concept tool) and has not been subject to
any heavy optimization attempt.
3) With gcc, something that has had a marked effect on compile time
performance and size of the executable is debug info generation.
Adding -g to the command line would increase the executable size by a
factor of 30 in some degenerate cases and slow down compile time by a
factor of 10. With more recent gccs (the 4.x series), this has
improved a lot.
I have never measured any runtime performance hit with using
metaprogramming.
HTH,
--
gpd
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]