On Aug 4, 2010, at 3:00 PM, Matt Fowles wrote: > > Doug Lea (of java.util.Concurrent fame) designed a framework called Fork/Join > which is made to separate the idea of work from threads so that things can be > parallelized out as much as possible. I don't know clojure that well, but > would guess that it has some support for it and that you would see the best > parallel fan out if you use the framework instead of explicitly managing your > thread counts like this.
Hmm -- apparently there's some Fork/Join support but it is deprecated (http://clojure.org/other_libraries). FWIW I'm not explicitly managing thread counts in any of my code -- I'm letting pmap do it or whatever is behind the management of "send"s to agents or the forcing of futures. I added Armando's suggest "burn-via-pool" test, which does explicitly manage threads, just to see what that would do, but one of the appeals of Clojure's concurrency support is that I shouldn't (I hope!) have to think about this... -Lee -- Lee Spector, Professor of Computer Science School of Cognitive Science, Hampshire College 893 West Street, Amherst, MA 01002-3359 lspec...@hampshire.edu, http://hampshire.edu/lspector/ Phone: 413-559-5352, Fax: 413-559-5438 Check out Genetic Programming and Evolvable Machines: http://www.springer.com/10710 - http://gpemjournal.blogspot.com/ -- 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