Re: [boost] [msm] scalability

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.

Thanks,
      Andy.