Have you checked for other sources of performance hits? Boxing, var lookups, and especially reflection.
I'd expect a reasonably optimized Clojure version to outperform a Python version by a very large factor -- 10x just for being JITted JVM bytecode instead of interpreted Python, times another however-many-cores-you-have for core.async keeping all your processors warm vs. Python and its GIL limiting the Python version to single-threaded performance. If your Clojure version is 2.5x *slower* then it's probably capable of a *hundredfold* speedup somewhere, which suggests reflection (typically a 10x penalty if happening heavily in inner loops) *and* another sizable performance degrader* are combining here. Unless, again, you're measuring mostly overhead and not real workload on the Clojure side, but not on the Python side. Put a significant load into each goroutine in both versions and compare them then, see if that helps the Clojure version much more than the Python one for some reason. * The other degrader would need to multiply with, not just add to, the reflection, too. That suggests either blocking (reflection making that worse by reflection in one thread/go holding up progress systemwide for 10x as long as without reflection) or else excess/discarded work (10x penalty for reflection, times 10x as many calls as needed to get the job done due to transaction retries, poor algo, or something, would get you a 100-fold slowdown -- but retries of swap! or dosync shouldn't be a factor if you're eschewing those in favor of go blocks for coordination...) On Fri, Nov 29, 2013 at 10:13 PM, Ben Mabey <b...@benmabey.com> wrote: > 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. > -- -- 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.
