I am simulation a network of roads, sources and sinks of materials, and trucks hauling between sinks and sources. There is not much of a workload - the complexity arises from having hundreds of trucks going through their states and queuing at the sources/sinks. So the bulk of the simulation consists of putting events on a priority queue. Maybe channels are simply not the right tool for that - or maybe I should just be happy with being able to simulate 10^5 trucks in a few seconds ;)
On Saturday, 30 November 2013 14:46:24 UTC+10:30, Cedric Greevey wrote: > > On Fri, Nov 29, 2013 at 11:03 PM, Ben Mabey <b...@benmabey.com<javascript:> > > wrote: > >> On 11/29/13, 8:33 PM, Cedric Greevey wrote: >> >> Have you checked for other sources of performance hits? Boxing, var >> lookups, and especially reflection. >> >> As I said, I haven't done any optimization yet. :) I did check for >> reflection though and didn't see any. >> >> >> 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. >> >> This task does not benefit from the multiplexing that core.async >> provides, at least not in the case of a single simulation which has no >> clear logical partition that can be run in parallel. The primary benefit >> that core.async is providing in this case is to escape from call-back hell. >> > > Hmm. Then you're still looking for a 25-fold slowdown somewhere. It's hard > to get Clojure to run that slow *without* reflection, unless you're hitting > one of those cases where parallelizing actually makes things worse. Hmm; > core.async will be trying to multithread your code, even while the nature > of the task is limiting it to effectively serial performance anyway due to > blocking. Perhaps you're getting some of the slowdown from context switches > that aren't buying you anything for what they cost? The GIL-afflicted > Python code wouldn't be impacted by the cost of context switches, by > contrast. > -- -- 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.
