On Fri Nov 29 17:04:59 2013, kandre wrote:
Here is the gist: https://gist.github.com/anonymous/7713596
Please not that there's no ordering of time for this simple example
and there's only one event (timeout). This is not what I intend to use
but it shows the problem.
Simulating 10^5 steps this way takes ~1.5s
Cheers
Andreas
On Saturday, 30 November 2013 09:31:08 UTC+10:30, kandre wrote:
I think I can provide you with a little code snipped.
I am talking about the very basic car example
(driving->parking->driving). Running the sim using core.async
takes about 1s for 10^5 steps whereas the simpy version takes less
than 1s for 10^6 iterations on my vm.
Cheers
Andreas
On Saturday, 30 November 2013 09:22:22 UTC+10:30, Ben Mabey wrote:
On Fri Nov 29 14:13:16 2013, kandre wrote:
> Thanks for all the replies. I accidentally left out the
close! When I contrived the example. I am using core.async for
a discrete event simulation system. There are hundreds of go
blocks all doing little but putting a sequence of events onto
a channel and one go block advancing taking these events and
advancing the time similar to simpy.readthedocs.org/
<http://simpy.readthedocs.org/>
>
> The basic one car example under the previous link executes
about 10 times faster than the same example using core.a sync.
>
Hi Andreas,
I've been using core.async for DES as well since I think the
process-based approach is useful. I could try doing the same
simulation you're attempting to see how my approach compares
speed-wise. Are you talking about the car wash or the gas
station
simulation? Posting a gist of what you have will be helpful
so I can
use the same parameters.
-Ben
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I've verified your results and compared it with an implementation using
my library. My version runs 1.25x faster than yours and that is with
an actual priority queue behind the scheduling for correct
simulation/time semantics. However, mine is still 2x slower than the
simpy version. Gist with benchmarks:
https://gist.github.com/bmabey/7714431
simpy is a mature library with lots of performance tweaking and I have
done no optimizations so far. My library is a thin wrapping around
core.async with a few hooks into the internals and so I would expect
that most of the time is being spent in core.async (again, I have done
zero profiling to actually verify this). So, it may be that core.async
is slower than python generators for this particular use case. I
should say that this use case is odd in that our task is a serial one
and so we don't get any benefit from having a threadpool to multiplex
across (in fact the context switching may be harmful).
In my case the current slower speeds are vastly outweighed by the
benefits:
* can run multiple simulations in parallel for sensitivity analysis
* I plan on eventually targeting Clojurescript for visualization
(right now an event stream from JVM is used)
* ability to leverage CEP libraries for advanced stats
* being integrated into my production systems via channels which does
all the real decision making in the sims.
This means I can do sensitivity analysis on different policies
using actual production code. A nice side benefit of this is that I
get a free integration test. :)
Having said all that I am still exploring the use of core.async for DES
and have not yet replaced my event-based simulator. I most likely will
replace at least parts of my simulations that have a lot of nested
call-backs that make things hard to reason about.
-Ben
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
