[ANN] Claypoole: Threadpool Tools for Clojure

The Climate Corporation has open-sourced the library claypoole, which is a set of threadpool tools for Clojure's parallel functions. For instance, you can start futures in a specific threadpool, pmap on a threadpool, or even use a parallel fo

Re: Clojure generates unnecessary and slow type-checks

I got nothin'. Stare at the bytecode? On Tue, Jul 2, 2013 at 11:21 AM, Jim - FooBar(); wrote: > with a long counter it needs slightly longer (216 microseconds in > average instead of 196)! > any other ideas? > > > On 02/07/13 19:11, Leon Barrett wrote: > > Try l

Re: Clojure generates unnecessary and slow type-checks

Try longs instead of ints? Clojure doesn't support local ints, so you may be casting longs to ints a lot. On Tue, Jul 2, 2013 at 11:05 AM, Jim - FooBar(); wrote: > I'm really sorry for coming back to this but even after everything we > learned I'm still not able to get performance equal to java

Re: Namespace qualification of symbols

Yes, it's expected, and if you need unqualified names you need to carefully unquote and requote, e.g. (defmacro def-a-fn [body] `(defn ~'a-fn ;; you can only define unqualified names, I think [] ~@body)) On Wed, Jun 19, 2013 at 3:32 AM, Jim wrote: > On 19/06/13 09:46, Phillip Lord wrot

Re: Clojure generates unnecessary and slow type-checks

Holy crap, the ^:replace seems to improve my example to the performance of Java! I'm looking further, but that may be the key. On Tue, Jun 18, 2013 at 11:12 AM, Stuart Sierra wrote: > One has to be very careful with this kind of > micro-benchmarking on the JVM. Dead-code elimination can > easil

Re: Clojure in production

At The Climate Corporation (formerly Weatherbill), we do much, though not all, of our development in Clojure. On Thursday, June 13, 2013 11:45:42 AM UTC-7, dgrnbrg wrote: > > We are using Clojure at Two Sigma to monitor, schedule, and optimize our > cluster. > > On a re

Clojure generates unnecessary and slow type-checks

44: areturn As far as I can tell, Clojure generated a checkcast opcode that tests on every loop to make sure the double array is really a double array. When I remove that checkcast, I get a 1/3 speedup (meaning it's a 50% overhead). Can someone help me figure out how to avoid this over

Re: bug in 'extend-protocol' ???

On Thu, Jun 13, 2013 at 10:52 AM, Jim - FooBar(); wrote: > On 13/06/13 18:47, Jim - FooBar(); wrote: > >> On 13/06/13 18:28, Leon Barrett wrote: >> >>> It shouldn't be necessary to examine the source to know what's going on >>> in a builtin, really,

Re: while loop

Yeah, Clojure's while construct isn't really good at stuff like that. A loop is the basic thing I reach for, and I'd probably write it as: (loop [] (when-let [entry (.getNextEntry stream)] (println entry) (recur))) On Thursday, June 13, 2013 10:20:22 AM UTC-7, Josh Kamau wrote: > > Hi

Re: bug in 'extend-protocol' ???

It shouldn't be necessary to examine the source to know what's going on in a builtin, really, but I also encountered this one recently. The way the extend-protocol macro finds which entries are types and which are function definitions is by checking which are lists. Frankly, a better macro woul