commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "r.c.hoekstra" <r.c.hoeks...@scarlet.nl>
Subject Re: [scxml] looking for developer for adaptations on Commons SCXML
Date Mon, 04 Dec 2017 17:35:34 GMT
Hi Jake,

thanks for your response.
I'll look into SCION too; even if we won't use it it might bring some 
inspiration on how to tackle things.

on scaling:
we are currently planning to experiment with running it on a 
supercomputer, which also has its disadvantages (planning, etc).

On serialization: that will most likely solve memory problems, but I 
doubt that it will be faster. But I must confess I have no experience 
with it. The suggestions are interesting enough to do some more 
exploration.

thanks,

Rinke


On 30-11-17 15:51, Jacob Beard wrote:
> Hi Rinke,
>
> SCION <https://github.com/jbeard4/SCION> is designed to support 
> expensive compilation of an in-memory model, followed by cheap 
> instantiation of new instances. However, as you can see in Stefan's 
> results, its runtime performance is currently much slower than 
> alternatives. It's hard to imagine a faster runtime than generated C 
> code, which uscxml appears to support.
>
> As Martin Gainty suggested, to do truly massive simulations supporting 
> millions of instances, you may need to scale your workload 
> horizontally across multiple servers. I think there are two approaches 
> to horizontally distributed state machine simulation. The first is to 
> assign each state machine instance to a dedicated machine, where state 
> will be kept in memory until it reaches its final state and can be 
> garbage collected. The second approach is to serialize each state 
> machine state to a database after processing an event; and re-hydrate 
> the state machine instance from the state stored in the database on 
> processing the next event. This second approach has been used 
> successfully to scale simulation across a cluster.
>
> Different SCXML implementations have varying levels of support for 
> serializing state machine instances. For example, SCION supports 
> serialization 
> <https://github.com/jbeard4/SCION-CORE#scgetsnapshot--snapshot> 
> directly, and this can also be achieved 
> <https://dzone.com/articles/persistent-state-machine> with SCXML Commons.
>
> Hope this helps. Good luck,
>
> Jake
>
>
>
> On 11/30/2017 04:27 AM, r.c.hoekstra wrote:
>> Hi Jake,
>>
>> thanks for your reaction. That is a really useful comparison. And I 
>> can see that Apache commons SCXML isn't doing that bad, though the 
>> scale is of course logarithmic.
>>
>> Unfortunately the benchmarking didn't test our use case:  we need to 
>> fire up many instances of the same (relatively simple) scxml model, 
>> and if instantiating is relatively expensive, that might change the 
>> picture completely.
>>
>> I'll look into uscxml and do some speed testing on that.
>>
>> best, Rinke
>>
>>
>>
>>
>> On 29-11-17 20:22, Jacob Beard wrote:
>>> Hi,
>>>
>>> I thought you might be interested in Stefan Radomski's work on 
>>> profiling different SCXML implementations:
>>>
>>> http://lists.w3.org/Archives/Public/www-voice/2017JulSep/0000.html
>>>
>>> https://github.com/tklab-tud/uscxml/blob/master/docs/BENCHMARKS.md
>>>
>>> This indicates that the uscxml implementation is pretty fast. It is 
>>> written in C++, so you would need to write additional code around it 
>>> to get it to work within the context of your Java programming 
>>> environment, but this might be faster than trying to improve the 
>>> performance of Apache Commons SCXML by an order of magnitude.
>>>
>>> I hope this helps. Thanks,
>>>
>>> Jake
>>>
>>>
>>> On 11/29/2017 06:56 AM, r.c.hoekstra wrote:
>>>> Hi List,
>>>>
>>>> We are working at the ErasmusMC hospital at Rotterdam, Netherlands, 
>>>> on scientific simulations on the spread of infectious diseases 
>>>> through human populations.
>>>> In this project we use Apache Commons SCXML to model diseases.
>>>>
>>>> However, the problem with the present implementation is that it is 
>>>> too slow for us. We would need a version that is optimized for 
>>>> being instantiated 1000000 times in a running simulation.
>>>>
>>>> For the coming 2 or 3 months we have money available to pay someone 
>>>> who could create an adapted, descaled version of apache commons 
>>>> scxml. The goal is to make it much faster, either by optimizing, 
>>>> rewriting, and dispose of elements not needed for us.
>>>>
>>>> Our preference would be to find someone who has developed for the 
>>>> commons scxml project, or who is at least an experienced user.
>>>>
>>>> In case of anyone interested please reply via this list and we can 
>>>> get into contact about the details.
>>>>
>>>> best regards,
>>>>
>>>> Rinke Hoekstra
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message