Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?

Subject: Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?
From: Kris (krzysztof_at_[hidden])
Date: 2016-02-05 07:11:41

On Wed, Feb 3, 2016 at 9:51 PM, Krzysztof Jusiak <krzysztof_at_[hidden]>
wrote:

> On Wed, Feb 3, 2016 at 8:51 PM, Christophe Henry-2 [via Boost] <
> ml-node+s2283326n4683176h75_at_[hidden]> wrote:
>
>> >I added a simple benchmark using Boost.MSM3-eUML2 to the performance
>> tests.
>> >Results can be found here ->
>> >
>> http://boost-experimental.github.io/msm-lite/overview/index.html#performance
>> >
>> >It seems that Boost.MSM3-eUML2 (not sure what is the proper name?)
>> compiles
>> >2.5 times slower than the eUML, but maybe there are some flags/options
>> to
>> >speed it up?
>> >
>> >Moreover, I'm not sure how to disable the slowing down options such as
>> >deffered events etc.?
>> >I would assume it should be as fast as eUML as it using the same
>> back-end?
>>
>> Compile-time is proportional to string length, reducing it would help.
>> So would reducing BOOST_MPL_LIMIT_STRING_SIZE.
>>
>> As they are empty, you can also remove you action definitions.
>>
>>
> Cheers, I have been experimenting with BOOST_MPL_LIMIT_STRING_SIZE already.
> However, it would be a bit bias to remove actions/guards in order to speed
> it up as it would not reflect the real life example. I know they are not
> doing much in the example, but
> they still have to be called or removed by the compiler depending on the
> approach.
> For example msm-lite is affected by empty guards/actions if it comes to
> memory size as it stores them in order to call lambda expressions.
>
>

I added composite and complex tests using eUML2 front end ->
http://boost-experimental.github.io/msm-lite/overview/index.html#performance
Actually, I haven't noticed a huge trade-offs whilst limiting
BOOST_MPL_LIMIT_STRING_SIZE length - max around 20%.
Anyway, interesting finding is the fact that eUML2, although compiling
around 2.5x time slower than eUML, compiles faster on the complex test
using Clang!
On GCC is still 2x slower then eUML but Clang has done some amazing job
here. Ah, I have also figured out why eUML2 was slower than eUML in my
previous
tests. I had to disable exceptions, message queue add add empty
no_transition handler.
Hope you find the results interesting too.

>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>>
>> ------------------------------
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://boost.2283326.n4.nabble.com/MSM-Is-there-any-interest-in-C-14-Boost-MSM-eUML-like-library-which-compiles-up-to-60x-quicker-whils-tp4683016p4683176.html
>> To unsubscribe from [MSM] Is there any interest in C++14 Boost.MSM-eUML
>> like library which compiles up to 60x quicker whilst being a slightly
>> faster too?, click here
>> <http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4683016&code=a3J6eXN6dG9mQGp1c2lhay5uZXR8NDY4MzAxNnwtMTY0MTkzNTIwMA==>
>> .
>> NAML
>> <http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>

--
View this message in context: http://boost.2283326.n4.nabble.com/MSM-Is-there-any-interest-in-C-14-Boost-MSM-eUML-like-library-which-compiles-up-to-60x-quicker-whils-tp4683016p4683249.html
Sent from the Boost - Dev mailing list archive at Nabble.com.