On 14/01/13 21:27, Jim - FooBar(); wrote:
On 14/01/13 20:47, Marko Topolnik wrote:
What exactly is the value provided by ExecutorCompletionService? To
my eyes, this function is quite similar to (comp doall pmap), but
with shuffled result. There is no advantage to using the lazy
approach to submitting tasks: you could have simply used invokeAll:
I think the advantage of ExecutorCompletionService is that , it will
give you back any of the futures that finished , not necessarily the
first but that which finished first (this is why you lose ordering as
well). It is certainly idiomatic, at least in Java, to do that...When
you submit to the completion service , it submits to the executor-pool
it is wrapping...I think your version will behave as pmap, meaning
that realising the result of '(map #(.get %) r)' will potentially
block if the 1st item (or the first items in general) takes ages to
finish and that is one of the problems with pmap. It won't move on to
the 2nd chunk unless all tasks from the 1st chunk have completed. This
is why pmap will not work well when you have irregularly sized data
leading to irregularly sized execution times per task...I 've been
bitten before by this and this is why I am using pool-map
instead...The completion service will return whatever future has
completed (if any) which gives more time to the longer tasks to
comlete... I don't have any links to share at the moment but several
hours of googling has led me to this...some of the best Java code that
I saw uses this as well (when the ordering doesn't matter).
Jim
--
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
