Re: core.async and performance

Did you look into Pulsar https://github.com/puniverse/pulsar ? I'm using core.async in the browser, but I don't see it as a multithreading mechanism. Pulsar puts an erlang-like api around the quasar lightweight threads and actors for java. Looks really nice, and seems a good fit for dse type a

Re: core.async and performance

That indeed provided a huge speed-up (0.5s compared to 1.5 originally). Cheers Timothy On Sunday, 1 December 2013 02:19:44 UTC+10:30, tbc++ wrote: > > There's several ways the performance of this code can be improved. > > Firstly, these are exactly the same (samantically), but the latter is much

Re: core.async and performance

There's several ways the performance of this code can be improved. Firstly, these are exactly the same (samantically), but the latter is much faster: (go (>! c v)) and (put! c v). Use put! whenever possible. Secondly, the function "event" uses ! (:queue @env) {:type type :val val

Re: core.async and performance

On Fri Nov 29 22:30:45 2013, kandre wrote: Maybe I'll just use my simpy models for now and wait for clj-sim ;) Any chance of sharing? Cheers Andreas On Saturday, 30 November 2013 15:40:10 UTC+10:30, Ben Mabey wrote: On 11/29/13, 9:16 PM, Cedric Greevey wrote: On Fri, Nov 29, 2013 at 11

Re: core.async and performance

Maybe I'll just use my simpy models for now and wait for clj-sim ;) Any chance of sharing? Cheers Andreas On Saturday, 30 November 2013 15:40:10 UTC+10:30, Ben Mabey wrote: > > On 11/29/13, 9:16 PM, Cedric Greevey wrote: > > On Fri, Nov 29, 2013 at 11:03 PM, Ben Mabey > > wrote: > >> On 11/2

Re: core.async and performance

On 11/29/13, 9:16 PM, Cedric Greevey wrote: On Fri, Nov 29, 2013 at 11:03 PM, Ben Mabey > 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 sa

Re: core.async and performance

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 con

Re: core.async and performance

On Fri, Nov 29, 2013 at 11:03 PM, Ben Mabey 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 tho

Re: core.async and performance

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 Clojur

Re: core.async and performance

Hmm. Another possibility, though remote, is that the Clojure version manages to trigger pathological worst-case behavior in the JIT and/or hardware (frequent cache misses, usually-wrong branch prediction, etc.) and the Python version doesn't (no JIT and maybe the interpreter is simply too slow to m

Re: core.async and performance

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 how

Re: core.async and performance

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 wa

Re: core.async and performance

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,

Re: core.async and performance

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,

Re: core.async and performance

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

Re: core.async and performance

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 even

Re: core.async and performance

This is all good advice. Also notice that these examples don't really match real life use cases of core.async. Here you only have two threads, where the execution time is dominated by message passing. In most situations you'll have dozens (or hundreds) of gos, with actual work being done in each lo

Re: core.async and performance

Ah forgot that the core.async folks mentioned that if you want performance its best to use real threads. (time (let [c (chan 100)] (thread (dotimes [i 10] (>!! c i)) (close! c)) (prn (wrote: > On Fri, Nov 29, 2013 at 1:09 AM, Thomas Heller > wrote: > > I'm actually surpr

Re: core.async and performance

On Fri, Nov 29, 2013 at 1:09 AM, Thomas Heller wrote: > I'm actually surprised you get to "stop" at all. You send a couple items > onto the channel but don't close it, therefore the 2nd go block will > potentially block forever waiting for more. Indeed. When I tried Andreas' code in the REPL, it

Re: core.async and performance

Hey, I'm actually surprised you get to "stop" at all. You send a couple items onto the channel but don't close it, therefore the 2nd go block will potentially block forever waiting for more. I'm far from an expert in core.async but I think the solution would be to close! the channel and as a s

core.async and performance

Hi there, I've started playing with core.async but I am not sure if I'm using it the way it was intended to. Running a simple benchmark with two go-blocks (one writing an event to a channel, the other one reading it out) seems quite slow: (time (let [c (chan 100) stop (chan)] (go (dotime