Subject: Re: [boost] [msm] scalability
From: Andy Venikov (avenikov_at_[hidden])
Date: 2009-12-11 11:09:19
Christophe Henry wrote:
> You're right, I could explain more in the documentation.
> Unfortunately, the answer is not straightforward.
> The compilation time (and how far the compiler plays with us) depends
> on a number of factors:
> 1) the compiler
> 2) the compiler version
> 3) even your hardware (I get very different compile times on 2
> different machines with the same processor)
> 4) the state machine structure and the chosen front-end
> 1) usually, g++ crashes later than VC and needed fewer workarounds
> 2) Surprisingly, g++4.2 > g++ 4.4. VC10 > VC9 > VC8
> 3) you will need RAM, especially with VC8
> 4) the compile-time is proportional to the number of transitions in
> the transition table and to the depth of the state machine (meaning
> submachine of submachine of...). EUML will cost you much more with VC
> than g++ as it implies a metaprogramming layer above the standard
> metaprogramming of the standard front-end and because the underlying
> decltype/typeof seems much better implemented with g++ (if you don't
> count the generated code size).
Christophe, I'm sorry if my 2 cents won't be relevant since I'm not very
familiar with neither MSM nor with MPL, but I have experience doing m-p
with some in-house libraries.
The most common reason for compiler slowliness/crashiness that I've seen
came from too deep of a template recursion. I'm not totally sure, but I
think that you're using mpl::vector, which, I think, is a form of a type
list. Type lists have a recursion depth equal the number of elements in
the list. In my work I ended up using type trees which have a recursion
depth of log(number_of_types) and that greatly increased compiler's
resiliency in the face of the increasing number of types. Sometimes it
even increased compilation speed. I'm not sure if MPL has type trees or
not, but they aren't hard to implement.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk