- Boost - lists.boost.org

Re: [boost] [Boost-users] Updated performance results using Boost Serialization 1.41
by Brian Wood 07 Dec '09

07 Dec '09

Kim Barrett writes: >On Dec 4, 2009, at 7:11 PM, Hartmut Kaiser wrote: >> Our measurements show Boost.Serialization spends most of its time creating >> (constructing) archives and there it's mainly initializing the locale... > > The locale initialization can be avoided if your application can get away with using the > boost::archive::no_codecvt construction flag. (Assuming that's still behaving the same > as when I looked into this performance area back around boost 1.33.) > > These threads may also be of interest: > > http://lists.boost.org/Archives/boost/2005/07/90814.php Based on that link I tried it as follows: int const binary_archive_flags = boost::archive::no_header | boost::archive::no_codecvt; filebuf fb; fb.open("ofile", ios_base::out); binary_oarchive oa(fb, binary_archive_flags); clock_t start(clock()); oa << lst; clock_t end(clock()); I didn't discern any improvement to the performance of this test from adding those flags. > http://lists.boost.org/Archives/boost/2006/03/102133.php I don't see how that is relevant. > > I keep promising myself that I will soon collect sufficient round tuits to do something > about this, but so far those promises remain broken. Maybe once I upgrade my team to boost 1.41. -- Brian Wood Ebenezer Enterprises http://www.webEbenezer.net

1 0

Re: [boost] [Boost-users] Updated performance results using Boost Serialization 1.41
by Brian Wood 07 Dec '09

07 Dec '09

Hartmut Kaiser writes: > Our measurements show Boost.Serialization spends most of its time creating > (constructing) archives and there it's mainly initializing the locale... That seems a little different from what I've been testing. The test looks like this: filebuf fb; fb.open("ofile", ios_base::out); binary_oarchive oa(fb); clock_t start(clock()); oa << lst; clock_t end(clock()); The time to construct an oarchive is not included in the test. -- Brian Wood Ebenezer Enterprises http://www.webEbenezer.net

1 0

Re: [boost] [msm] internal/external conflicting transitions
by Christophe Henry 07 Dec '09

07 Dec '09

Hi Michael, >I'm hoping to test it thoroughly. I'm an HFSM geek and >ROOM/UML implementations are part of my livelihood. Great! Welcome to the club (though you probably were there before me). >Ok. So I think this is part of the issue. As you know, UML defines three >types of states: simple, composite and submachines. It appears that >MSM implements simple and maybe submachines. I'm still unclear on >what MSM exactly has and will write another email on the subject after >I have sorted it all out. MSM supports all but implements submachines and composite as one concept because I consider the difference isn't worth bringing 2 words. >Transitions can be either internal or external. Even for simple states. >An internal transition in a simple state will never execute exit or >entry code. I didn't find this in the standard, but I might have missed it out. Whatever, after a lengthy discussion with Juraj Ivancic, I came to the conclusion that MSM needed what we called an "execution row", which is pretty much your internal transitions for simple states. >And this is where I was unclear. A better question would be: For >a simple state, how do I create an internal transition? For the moment, you can't easily. The only way would be to specialize on_entry and on_exit on some events, but this is less than perfect, so this feature is quite at the top of my list. >This also disturbs me a bit... though it isn't your problem. Bran Selic >for some reason changed this behavior in UML. It used to be much more >well defined. Internal transitions were always evaluated before external >transitions. I don't know about that change, but I know that this depth-first strategy has some critics (which I failed to understand). Whatever, after the new type of row for simple states is added, you'll be able to define it wherever you want in the transition table and can therefore decide yourself of the priority. You will not however be able to do it for rows coming from composites because MSM will handle it alone, otherwise it'd break the exit points. I think it is a reasonable solution. >Perfect! This is what I wanted to know. I think it would be helpful >to describe the run-to-completion semantics (including the ordering) >in the documentation as well as a summary of rules for conflict >resolution. I do like the "last transition wins" rule you have >created. I also understand defining it as undefined (implementation-specific) >behavior. This has already been requested and will be done, along with a complete description of the dispatch algorithm. Christophe

2 1

Re: [boost] [msm] Review
by Christophe Henry 07 Dec '09

07 Dec '09

>I would expect both libraries to allow either mpl::vector or mpl::list. Sure. That the examples use mpl::vector doesn't mean list would not work.

1 0

Re: [boost] [msm] history pseudo states
by Christophe Henry 07 Dec '09

07 Dec '09

>I apologize. I'm still not clear on the distaste. Ignoring regions >for a minute.... does it make sense then? A composite state could >only have a single history. And the history's transition is the default >if the composite state hasn't been visited yet... so it makes sense >that there could only be one of those too. Not to apologize, I knew I was taking a risk when I decided to ignore this part of the standard. Sure, ignoring regions, shallow history makes sense. Except for the part about having to draw a transition from the top-level fsm to INSIDE the composite. Talk about UML favoring encapsulation... And if you count deep history, then it becomes even uglier. How do you mark the default state in the sub-submachine? I found no answer. >Adding in regions messes the whole thing up. And here might be >the sticking point. I can tell you that the history of "return to history" >was from an era without regions. In that context it is a very power >construct. Seeing the spec it is clear that regions were not included ;-) So, all this brought me to the conclusion that a policy was a greatly superior solution. Encapsulation ok, deep history ok, regions ok, and the possibility to define a new history policy. But I'm open to any solution answering my critics on this subjects. Of course, it's not the kind of solution that an OO-dominated body can come up with. Christophe

1 0

Re: [boost] [msm] Review
by Christophe Henry 07 Dec '09

07 Dec '09

Hi David, Thanks for bringing some depth to the discussion. >2. In Statechart, the definition of a state is coupled to the machine in which it resides > while in MSM the state can be defined totally in isolation of the machine, and, thus, reused in other machines >3. In Statechart, the transitions are coupled to the from-state, and defined therein, > whereas in MSM, the transitions are coupled to the machine itself; this makes it a bit tricky to reuse a state in Statechart This is an important interface difference, isn't it? > 5. MSM has eUML, which I have *not* used, to simplify the machine specification. I'd also count it as an important interface difference. You brought the following example, which will be a good starting point. Unfortunately, you seem to want to make it tell too much about Statechart/MSM similarities (I read "fairly similar") so let's tough it out a little. With Statechart, you had: struct State1 : simple_state<State1, Machine> { typedef transition<Event, State2, Machine, &Machine::action> reactions; }; And with MSM: typedef mpl::vector< a_row<State1, Event, State2, &Machine_::action> > transition_table; Now this example is a bit too simple to see a huge difference, so it is slightly misleading. If you don't mind, let's add a very simple thing, a guard (which is a boolean condition having the right to prevent the triggering of a transition). With MSM this becomes: typedef mpl::vector< row<State1, Event, State2, &Machine_::action, &Machine_::some_condition> > transition_table; Could you you maybe now show us how the Statechart version will look like? Let's now add a conflicting transition, which means another possible transition on the same event and the same source state, with guards deciding which (if any) transition will be taken. With MSM you'd have, for example: typedef mpl::vector< row<State1, Event, State2, &Machine_::action, &Machine_::some_condition>, row<State1, Event, State3, &Machine_::action, &Machine_::some_other_condition> > transition_table; Could you now write the Statechart version for us? How easy is your Statechart->MSM translator now? (Note: MSM->Statechart will stay pretty simple, right?) After seeing both versions, will we all agree that there are important interface differences and that these differences are an important distinguishing feature? Christophe

4 4

Re: [boost] Two FSM libraries, one interface
by Christophe Henry 07 Dec '09

07 Dec '09

>Out of curiosity, but since MSM is designed to have configurable >front-ends and back-ends, why cannot statemachine become a new >back-end and/or front-end to MSM? MSM supports everything >statemachine does so it should be possible with perhaps minor syntax >changes... You mean FSM_DEF? It could, but first it'd need to support a bit more to become interesting. If I have to maintain it, I want to be sure that it does what the other front-ends do. If I don't maintain it, then no problem for me.

1 0

[msm] history pseudo states
by Christophe Henry 07 Dec '09

07 Dec '09

Hi Michael, >>"To be frank, History is not a completely satisfying concept. First >>of all, there can be just one history pseudostate and only one >>transition may originate from it." >I'll not contend with the views of history yet. They can be a very >powerful concept. What I'm unclear about is the statement that >there can be just one. According to the UML specification there >can be just one per composite state. That of course makes perfect >sense. MSM has SubmachineStates instead of composite states; however, >the same "rule" applies to both. >Does MSM obey this definition or is there a further constraint? >My confusion might be partially attributed to not having finished >reading all of the docs. Sorry for the confusion which I created. Let me try to correct it. Yes of course, I meant one per composite state. And no it doesn't make perfect sense (at least for me) so there'll be a small constraint: History is not a pseudo state for MSM. I find the concept in UML highly dissatisfying. It simply doesn't fit well with orthogonal regions. What if I want to "remember" more than one region? With UML, you're out of luck: one history per composite, one transition originating from it. Want more? Sorry we can't help you. And with deep history, it is even worse. You don't even see for what region of the subcomposite it applies. And I don't see how adding a "*" is supposed to help. So MSM replaced this unfinished and unsatisfying concept with a policy. This allows you much better history configuration and easy deep history. I hope I managed to correct the created confusion. Christophe

2 1

Two FSM libraries, one interface
by Christophe Henry 07 Dec '09

07 Dec '09

Hi David, >Anyway, I just got tired of being a grumpy old passive man, so decided to put some of my money >(or time) where my mouth is. I will write more about this side effect of my analysis in a blog post later I find it great and worth of respect that you spent time making a useful contribution to the discussion by going the extra mile (or even 2-3) to present your point. While I am by no mean a friend of the preprocessor, I find your solution interesting and encourage you to push it a bit further by supporting at least guards. If you allow a few comments: - I suggest you to give the action a name because you won't always manage to name an action actState1EventState2, for example with 2 transitions with the same source and target. - this would also remove the need for direct code writing, which could break the preprocessor - What about adding some entry/exit? I'm sure you manage to pack this one too. Otherwise I find the idea surprising but fun and think that it could gain being pushed a bit further. If you do, you could even tempt me to reuse it in an eUML front-end ;-) Christophe

2 1

[msm] internal/external conflicting transitions
by Christophe Henry 07 Dec '09

07 Dec '09

Hi Michael, Looks like you are thoroughly testing MSM and I find it great :) >The docs have a section on "Conflicting Transitions". It has >two conflicts described: > >1. an event enables multiple transitions because > multiple guards test valid, > >2. an internal and external transition are both enabled > >I see a clear definition for the behavior of #1 in the >discussion; however, it is not clear that #2 will follow >the same rule. I was maybe unclear with "internal" so let's see if we can converge. With internal, I mean internal to a composite. Suppose we have a fsm named Top containing a state State and a composite Sub. Top has a transition on Event from Sub to State. Sub has 2 states, SubState1 and SubState2 and a transition on Event from SubState2 to SubState1. If the fsm is in the state Sub::SubState2 and Event is detected, we now have a conflict between Sub->State and SubState2->SubState1. UML defines this as a conflict and orders that SubState2->SubState1 wins. It also surprised me a bit until I implemented exit points, which are in themselves a conflict (they are defined as a connection between a transition inside a composite and one outside, triggered by the same event). So, if SubState1 were an exit point, it would still work. >It was actually a little surprising to me that the order <of the transition definitions affected #2. (Well, maybe >not surprising ... but not what I wanted). I used >the SimpleTutorial to test the behavior with: > > a_row < Stopped , play , Stopped , &p::test_conflict >, > a_row < Stopped , play , Playing , &p::start_playback >, > a_row < Stopped , open_close , Open , &p::open_drawer >, > >and > > a_row < Stopped , play , Playing , &p::start_playback >, > a_row < Stopped , play , Stopped , &p::test_conflict >, > a_row < Stopped , open_close , Open , &p::open_drawer >, > > >The last transition defined "wins" in a conflict. This is were I'm unsure if I follow you. SimpleTutorial has no composite, so no internal transition so we must be talking about different things. I can, however, still answer about the order of evaluation. UML orders that conflicts be solved by guards which are mutually exclusive, so your machine is currently ill-formed (no guards) and UML says the behavior is undefined and I, as implementer, am allowed to punish you like I wish ;-) Seriously, if you have guards and they are mutually exclusive, your machine is correct and all will work as expected, no matter the order of evaluation. If you still want to know how it works, with pleasure (this is where normal users could stop reading ;-) ). First, for every event used inside a composite, MSM adds a forwarding row at the end of your table (at the end, so they have no influence on the state index calculation system). Then, for a given event, MSM iterates at compile-time through the STT, from back to front and replaces the conflicts by a new row containing all of the conflicts (this is were your compiler suffers). Thus, transitions internal to a composite are given higher priority in the evaluation. This also means that for "normal" conflicts, the last transition wins. I was already asked if I would change it. It is implementation-specific so you should not rely on it, but it is very unlikely that I will ever want to change it. I hope I brought enough elements to bring clarity. If not, please let me know. Christophe

2 1