I took a look at the code, but it's not clear to me what it's supposed to be doing.
But, my suspicion is this algorithm could be expressed as a reduce, which means you could potentially use reducers on it and get fork/join concurrency for free. I think that's the case because it seems like these concurrent process are all banging on the same mutable state, racing each other, so to speak. I can't tell if that's intentional, but if you could describe the algorithm as work-splitting and result-combining, then it's likely reducers might work. http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html It would help to see a well-commented sequential version where all necessary state is contained within a loop/recur or a reduce accumulator, that doesn't rely on dynamic scoping (max-diff and max-factor). For instance: Here's how to find the max of a sequence of random ints using reduce: (reduce (fn [cur-max next-candidate] (max cur-max next-candidate)) ;; initial max Long/MIN_VALUE (take 10000 (repeatedly (partial rand-int 10000)))) To parallelize this, throw the input into a vector, then run it through reducers/fold. On Sat, Apr 12, 2014 at 3:18 PM, Cecil Westerhof <cldwester...@gmail.com>wrote: > 2014-04-12 17:19 GMT+02:00 Gary Trakhman <gary.trakh...@gmail.com>: > > I'd recommend running a doall on concurrent-list in order to realize the >> futures, if you simply deref as you are, then you're going to delay the >> execution of futures down the line as the sequence is realized bit by bit >> (except chunking helps you here by accident). You are effectively >> preventing later parts from getting realized until the earlier futures >> return. >> > > I want the threads to be finished when I do the deinit, that does not > happen when I use the doall. > > > But of course, there's likely a better approach, we'd need to know what >> you're trying to do to address it. >> > > I just started playing with Clojure a few days ago, so I am a tabula rasa. > I attached what I have until now. If it can be improved, I like to know it. > > -- > Cecil Westerhof > > -- > 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/d/optout. > -- 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/d/optout.
