Re: [boost] [msm] scalability

Subject: Re: [boost] [msm] scalability
From: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2009-12-10 07:23:42

Hi Jeff,

>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.

Great to have you back in 2009!

>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?

Sorry about it but probably not. The engine of 2.0 is based on the one
of 1.20 with an added (tiny) metaprogramming layer to convert the
front-end table to a back-end one. So it could be actually slower. Not
much with VC9 but I didn't measure with VC8. This tiny part was enough
to lose g++3.4 for good though :(

>Unfortunately the same code takes over 2.5 minutes on VC8
>Aah! I should mention these times are for debug builds
> 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.

Yes, VC8 is from far the slowest MSM-supporting compiler and debug is
the worst, in compile-time and ram usage.
I'm afraid, the best I can offer would be a mini-MSM backend based
mostly on the book example but supporting basic frontend features so
that at least you'll be able to switch the backend if you change
compiler one day.

I noticed that using precompiled headers will reduce the compile-time
by about a third.

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

What do you mean with inline? It sounds interesting.

>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.

Refactoring into regions is usually a good idea from a design point of
view. I didn't mean it as a pure compile-time reduction measure
though. I was just describing what, in my experienced, could reduce
the compile-time a little.
Do you maybe remember what increased your compile-times?

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

Thanks! It was a two-way street because MSM greatly gained from your
(and others') suggestions.

Christophe