I doubt whether any framework will optimize performance without some
sort of configuration. This fork/join example requires a threshold for
resorting to sequential processing and the number of threads allowed
at any one time:
MaxWithFJ mfj = new MaxWithFJ(problem, threshold);
ForkJoinExecutor fjPool = new ForkJoinPool(nThreads);
http://www.ibm.com/developerworks/java/library/j-jtp11137.html
Using the executor framework is by no means explicit thread
management. Depending of the chosen policy you get a particular way to
create, keep, and replentish threads. The idea of the thread pool
sample code was to see if keeping the contention up to the numbers of
cores would help performance, as opposed to the cached thread pool
used by (future) that will create any number of threads if no idle
ones are available.
On Aug 4, 3:29 pm, Lee Spector <lspec...@hampshire.edu> wrote:
> 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
