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-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
