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

[ANN] Slamhound 1.5.0 + screencast + Vim plugin

Hello, I am happy to announce version 1.5.0 of Slamhound, technomancy's amazing ns rewriting tool. ;; ~/.lein/profiles.clj {:user {:dependencies [[slamhound "1.5.0"]]}} This is a *major* bugfix release. If you've tried Slamhound in the past and felt frustrated, now is a great time to giv

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: quick macro review

I like the way you use (partial list 'var). On Thu, Nov 28, 2013 at 5:22 PM, juan.facorro wrote: > Hi Curtis, > > The *apply* is unnecessary if you use *unquote-splice* (*~@*), also > instead of the *into* and *for* usage you could just *map* over the list > of symbols. > > Here's how I would do

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: tails function?

On 30 Nov 2013, at 01:33, Mark Engelberg wrote: > (take-while seq (iterate rest [1 2 3 4])) D'oh! Told you I would kick myself. Thanks Mark. -- paul.butcher->msgCount++ Silverstone, Brands Hatch, Donington Park... Who says I have a one track mind? http://www.paulbutcher.com/ LinkedIn: http://

Re: tails function?

(take-while seq (iterate rest [1 2 3 4])) On Fri, Nov 29, 2013 at 5:17 PM, Paul Butcher wrote: > I fear that I'm missing something obvious here, so I'm getting ready to > kick myself. I'm looking for an equivalent of Scala's "tails" method: > > scala> List(1, 2, 3, 4).tails.toList > res0: List[

tails function?

I fear that I'm missing something obvious here, so I'm getting ready to kick myself. I'm looking for an equivalent of Scala's "tails" method: scala> List(1, 2, 3, 4).tails.toList res0: List[List[Int]] = List(List(1, 2, 3, 4), List(2, 3, 4), List(3, 4), List(4), List()) But I'm damned if I can f

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: Reactive Patterns with Atoms - am I using too much state?

On Nov 29, 2013, at 11:58 AM, Sam Ritchie wrote: > 2) a defstatefn macro that defines the "mark" and "mark!" versions at the > same time. I do that with agents: (def-action text :send [state number message]) … creates a `text*` and a `text>!`, where `test>!` is (defn text>! [number message]

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: [ANN] Buffy The ByteBuffer Slayer, Clojure library to working with binary data

Good work! Thanks! 2013/11/29 Alex P > Buffy [1] is a Clojure library to work with Binary Data, write complete > binary protocol implementations > in clojure, store your complex data structures in an off-heap chache, read > binary files and do > everything you would usually do `ByteBuffer`. > >

[ANN] Buffy The ByteBuffer Slayer, Clojure library to working with binary data

Buffy [1] is a Clojure library to work with Binary Data, write complete binary protocol implementations in clojure, store your complex data structures in an off-heap chache, read binary files and do everything you would usually do `ByteBuffer`. Main features & motivation to write it * partial

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: quick macro review

Beautiful, thanks guys. On Thursday, November 28, 2013 10:26:05 PM UTC-8, Alex Baranosky wrote: > > This also works, I believe: > > (defmacro migrate [& migration-syms] > (let [migration-vars (for [sym migration-syms] >`(var ~sym))] > `(migrate* ~@migration-va

Reactive Patterns with Atoms - am I using too much state?

Hey guys, As I start to work on more Clojurescript UI code, I've been running into a pattern with atoms and watches that I THINK I can abstract away... but the solution feels wrong, and I'd love to hear a better way. Say I'm building a stopwatch for timing runners in a race. I've got a cloju

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: [ANN]: clj.jdbc 0.1-beta1 - Alternative implementation of jdbc wrapper for clojure.

On Fri, Nov 29, 2013 at 3:38 AM, Lars Rune Nøstdal wrote: > Looks interesting. It even has the issue tracker on github still enabled. The reason contrib libraries (and Clojure itself) have the issue tracker disabled on Github is because they use JIRA for tracking issues - and pull requests are no

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: [ANN] Clara 0.3.0: Rete in ClojureScript

Cool! It remembers me when I was developing expert systems 30 years ago…..the eternal recurrence ;-) soon or later more devs will appreciate this wonderful unification language…. mimmo On Nov 29, 2013, at 4:49 PM, Ryan Brush wrote: > Clara 0.3.0, a forward-chaining rules engine in pure Clojure

Re: [ANN] Clara 0.3.0: Rete in ClojureScript

Congrats! Ambrose On Fri, Nov 29, 2013 at 11:49 PM, Ryan Brush wrote: > Clara 0.3.0, a forward-chaining rules engine in pure Clojure, has been > released. The headliner is ClojureScript support, although a handful of > fixes and optimizations were included as well. > > Some discussion of the

[ANN] Clara 0.3.0: Rete in ClojureScript

Clara 0.3.0, a forward-chaining rules engine in pure Clojure, has been released. The headliner is ClojureScript support, although a handful of fixes and optimizations were included as well. Some discussion of the ClojureScript port is in that group: https://groups.google.com/forum/#!topic/cloj

Re: [ANN]: clj.jdbc 0.1-beta1 - Alternative implementation of jdbc wrapper for clojure.

Looks interesting. It even has the issue tracker on github still enabled. -- -- 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 pati

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

Re: [ANN] projars.com

Hi Joshua, Your answer is very much appreciated. My hypothesis right now is that highly successful /open source/ projects, already having profit or not, can usually take care of themselves. As well as hardly any established software company needs a broker. But examples on everyone's lips are ve

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

Re: [ANN] projars.com

On Thu, Nov 28, 2013 at 2:53 AM, Bastien wrote: > > I'm working on a website where people will be able to ask donations > more easily for their FLOSS achievements and future projects, I'd love > to see both directions (more commercial options and more crowdfunded > FLOSS libraries) encouraged at