Re: [boost] [msm] scalability

Subject: Re: [boost] [msm] scalability
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2009-12-09 11:18:16

Hi Christophe,

I've dragged myself back to 2009 from 2004 where I've been stuck with 
CodeWarrior and an emulated OSX 10.3 environment with no chance of using 
  any modern boost libs. So I hope to have a review in by the end of the 
week.

Christophe Henry wrote:
> Hi Simon,
> 
>> I think it would be worthwhile talking a little more about compile time performance in the documentation.
> 
> 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

Indeed MSM 1.x showed g++4.2 much faster and uses less ram than VC8. Is 
MSM 2.x any faster or more ram frugal?

> 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).
> 
> A small test with VC9 in Release mode (and no other code) gave me:
> 20 transitions => 11s
> 30 transitions => 16s
> 40 transitions => 22s
> 50 transitions => 31s

For 41 transitions and 5 states, I was seeing about 30s on XCode with 
g++4.2.x.

Unfortunately the same code takes over 2.5 minutes on VC8. In fact so 
many compute resources were used that Incredibuild, our distributed 
build tool, was blocked from distributing any other compilation units 
for about 2 minutes. This forced me to revert to the TMP book's STT 
implementation which compiled in less than 30 seconds on both platforms, 
and allows Incredibuild to do it's job.

Aah! I should mention these times are for debug builds, which is a much 
more important measurement in an iterative/agile development 
environment. It's not that big of a deal if the nightly release build 
takes a few minutes longer. By the way I'm on XP with 4GB ram using the 
/3GB switch.

Interestingly if I just put all the MSM implementation inline there is 
about a 1 minute overall build time improvement.

> This is just to give you an idea as it can greatly depend on the
> factors named above.
> 
>> Also I'd like to see some suggestions of how to improve compile times (and how factors including the number of entries in a transition table affect the compile time).
> 
> There is just one solution: reduce the number of transitions. The best
> way to do it is using orthogonal regions. For example, if you see in
> your diagram many transitions to a single state based on the same
> event, you should factor them all into a second region.
> Adding submachines could help in some cases. On one hand, the compiler
> now has to generate code for a second machine, OTOH it reduces the
> number of transitions in the main one. This will only help if your
> submachine handles a small number of events, as Msm will add a row in
> the main table for every event of the submachines. If you can in
> exchange reduce the number of transitions, it can help.

My efforts at submachine refactoring actually increased compile times 
significantly. Also my main motivation for using the STT is it's ability 
to give both a forest-and-trees presentation of a moderately complex set 
of operations. Any refactoring just to get better compile times that 
obscures this ease of understanding just negates the benefits. Of course 
if refactoring into regions/zones exposes some underlying relations 
inherent in these states, transition and operations than it's fully 
justified, IMHO.

[snip]

> 
>> One of my favourite features of boost::statechart is state local storage.  It looks like this would have to be done manually in msm?
> 
> Yes, this is not supported yet. However, Msm has always been developed
> very user-oriented and what users ask, they usually get it. Msm has

I can attest to Christophe responsiveness and willingness to accommodate 
users needs.

Jeff